Method and system for providing internet services

• US 8,453,209 B2
• Filed: 06/25/2009
• Issued: 05/28/2013
• Est. Priority Date: 06/26/2008
• Status: Active Grant

• Current Assignee: Alibaba Group Holding Ltd.
• Original Assignee: Alibaba Group Holding Ltd.
• Inventors: Cen, Wenchu, Wang, Lin, Zhao, Jin, Zheng, Seshu, Zeng, Yi
• Primary Examiner(s): Pwu, Jeffrey
• Assistant Examiner(s): JHAVERI, JAYESH M
• Application Number:
  US12/459,005
• Publication Number:
  US 20090328174A1
• Time in Patent Office: 1,433 Days
• Field of Search: 726 2- 21, 726/26, 726/27, 726/29, 709227-229
• US Class Current: 726/4
• CPC Class Codes: G06F 21/30 Authentication, i.e. establishing the identity or authorisation of security principals
• CPC Class Codes: G06F 21/44 Program or device authentication
• CPC Class Codes: G06F 21/62 Protecting access to data via a platform, e.g. using keys or access control rules
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0884 by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
• CPC Class Codes: H04L 63/105 Multiple levels of security
• CPC Class Codes: H04L 63/12 Applying verification of the received information cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32
• CPC Class Codes: H04L 63/205 involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved negotiation of communication capabilities H04L69/24
• CPC Class Codes: H04L 67/51 Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 69/28 Timers or timing mechanisms used in protocols

Abstract

A service integration platform system for providing Internet services includes: an interface configured to receive a service request message that is initiated by a user of an application provided by an Independent Software Vendor (ISV), the service request message being implemented according to an Application Programming Interface (API) type and including a plurality of platform-level parameters that conform to the API type. The system further includes one or more processors coupled to the interface, configured to: locate a set of authentication checks that are appropriate for the API type, based at least in part on the plurality of platform-level parameters included in the service request message and a mapping of predefined combinations of platform-level parameters and corresponding sets of authentication checks; perform authentication of the service request according to the set of authentication checks; and route the service request to a service address of the Internet Service Provider (ISP) in the event that the service request is authenticated.

Claims

1. A method for providing web services with a service integration platform comprising:

receiving a service request message that is initiated by a user of an application provided by an Independent Software Vendor (ISV), the service request message being implemented according to an Application Programming Interface (API) type and including a plurality of platform-level parameters that conform to the API type, wherein;

the plurality of platform-level parameters comprise an Appkey associated with the application provided by the ISV;

the Appkey is a parameter issued to the application provided by the ISV and is not modifiable by the application provided by the ISV; and

the Appkey is a proof of identity that identifies the web services the application provided by the ISV is allowed to access;

determining, using a processor, a set of authentication checks that correspond to and that are appropriate for the API type, wherein;

the API type is one of a plurality of possible API types;

for each possible API type there is a corresponding set of authentication checks; and

at least some API types map to different sets of authentication checks;

performing authentication of the service request message according to the set of authentication checks;

routing the service request message to a service address of an Internet Service Provider (ISP) in the event that the service request message is authenticated, wherein the Internet Service Provider (ISP) is a provider of web services on the Internet;

maintaining a token list in a cache in the event that the platform parameters include service Internet Service Provider identity, the Appkey associated with the application, and user session uniqueness identity in the Independent Software Vendor application;

determining whether a token exists and is valid; and

returning user binding error information in the event that no token exists or the token is invalid;

wherein the API type has a corresponding service level comprising an authorized service type and the determined set of authentication checks includes a signature check and a timestamp check; and

wherein the platform-level parameters for the authorized service type further comprises a service name, a service request timestamp and a signature.

2. The method of claim 1, wherein the API type has a corresponding service level comprising an anonymity access type and the determined set of authentication checks includes zero elements.

3. The method of claim 1, wherein the plurality of platform-level parameters further comprises a service name.

4. The method of claim 1, wherein the API type has a corresponding service level comprising a user authorized service type and the determined set of authentication checks includes a signature check, a timestamp check and a user identity check.

5. The method of claim 4, wherein the platform-level parameters for the user authorized service type further comprises a service name, a service request timestamp, a signature and a user session uniqueness identity in the ISV application.

6. The method of claim 1, wherein the API type has a corresponding security level comprising an optional user authorized service type and the determined set of authentication checks includes a signature check, a timestamp check, and optionally, a user identity check.

7. The method of claim 6, wherein the platform-level parameters for the optional user authorized service type further comprises a service name, a service request timestamp and a signature, and optionally a user session uniqueness identity in the ISV application.

8. The method of claim 1, wherein the set of authentication checks comprises one or more of the following:

a signature check, a timestamp check and a user identity check.

9. The method of claim 1, wherein the platform-level parameters comprises one or more of the following:

a service name, a service request timestamp, a signature, a user session uniqueness identity in the Independent Software Vendor application and a type of returned value.

10. The method of claim 1, further comprising returning user binding error information.

11. The method of claim 10, wherein user binding error information is returned in the event that that the platform parameters include a user session uniqueness identity in the Independent Software Vendor application and the service request message authentication fails.

12. The method of claim 10, further comprising:

initiating a second service request message to a login address of the ISP upon receiving the user binding error information, wherein the second service request message includes as its platform-level parameters the Appkey associated with the application, a service name, a user session uniqueness identity in the Independent Software Vendor application and an address the Independent Software Vendor application to be redirected to upon passing user binding.

13. A service integration platform system for providing web services comprising:

an interface configured to receive a service request message that is initiated by a user of an application provided by an Independent Software Vendor (ISV), the service request message being implemented according to an Application Programming Interface (API) type and a plurality of platform-level parameters that conform to the API type, wherein;

the plurality of platform-level parameters comprise an Appkey associated with the application provided by the ISV;

the Appkey is a parameter issued to the application provided by the ISV and is not modifiable by the application provided by the ISV; and

the Appkey is a proof of identity that identifies the web services the application provided by the ISV is allowed to access; and

one or more processors coupled to the interface, configured to;

determine a set of authentication checks that correspond to and that are appropriate for the API type, wherein;

the API type is one of a plurality of possible API types;

for each possible API type there is a corresponding set of authentication checks; and

at least some API types map to different sets of authentication checks;

perform authentication of the service request according to the set of authentication checks;

route the service request to a service address of an Internet Service Provider (ISP) in the event that the service request is authenticated, wherein the Internet Service Provider (ISP) is a provider of web services on the internet;

maintain a token list in a cache in the event that the platform parameters include service Internet Service Provider identity, the Appkey associated with the application and user session uniqueness identity in the Independent Software Vendor application;

determine whether a token exists and is valid; and

return user binding error information in the event that no token exists or the token is invalid;

wherein the API type has a corresponding service level comprising an authorized service type and the determined set of authentication checks includes a signature check and a timestamp check; and

wherein the platform-level parameters for the authorized service type further comprises a service name, a service request timestamp and a signature.

14. The system of claim 13, wherein the API type has a corresponding service level comprising an anonymity access type and the set of determined authentication checks includes zero elements.

15. The system of claim 13, wherein the plurality of platform-level parameters further comprises a service name.

16. The system of claim 13, wherein the API type has a corresponding service level comprising a user authorized service type and the determined set of authentication checks includes a signature check, a timestamp check and a user identity check.

17. The system of claim 16, wherein the platform-level parameters for the user authorized service type further comprises a service name, a service request timestamp, a signature and a user session uniqueness identity in the ISV application.

18. The system of claim 13, wherein the API type has a corresponding service level comprising an optional user authorized service type and the determined set of authentication checks includes a signature check, a timestamp check and optionally, a user identity check.

19. The system of claim 18, wherein the platform-level parameters for the optional user authorized service type further comprises a service name, a service request timestamp and a signature, and optionally a user session uniqueness identity in the ISV application.

20. The system of claim 13, wherein the set of authentication checks comprises one or more of the following:

a signature check, a timestamp check and a user identity check.

21. The system of claim 13, wherein the platform-level parameters comprises one or more of the following:

a service name, a service request timestamp, a signature, a user session uniqueness identity in the Independent Software Vendor application and a type of returned value.

22. The system of claim 13, further comprising returning user binding error information.

23. The system of claim 22, wherein user binding error information is returned in the event that that the platform parameters include a user session uniqueness identity in the Independent Software Vendor application and the service request message authentication fails.

24. The system of claim 22, herein the one or more processors are further configured to:

initiate a second service request message to a login address of the ISP upon receiving the user binding error information, wherein the second service request message includes as its platform-level parameters the Appkey associated with the application, a service name, a user session uniqueness identity in the Independent Software Vendor application and an address the Independent Software Vendor application to be redirected to upon passing user binding.