KR102502167B1 - Service providing method based on cloud platform and system thereof - Google Patents

Abstract

A system for providing a service provided through the cloud, a device for providing the service, and a method for providing the service are provided. A method of providing a service using a cloud platform separately issues a user authentication token for authenticating a user and a service token for authenticating a service, and delivers the user authentication token and service token together when calling an API through a service gateway. Thus, the service gateway requests verification of the service token from the authentication information provider (IdP).

Description

Service provision method and system based on cloud platform

It relates to a system for providing a service provided through a cloud, a device for providing a service, and a service providing method. More specifically, it relates to a system, apparatus, and method for efficiently processing authentication performed to provide a service through a cloud.

When providing services through the cloud, users can access services through user authentication to prove users for security and service authentication, which is authentication to allow access to services. When a user wants to access a service, a developer develops an application programming interface (API) of the service through a cloud platform, or an end user develops an API of a service provided through a cloud platform. means if you want to use .

In order to perform user authentication and service authentication when a user wants to access a service, the system constituting the cloud platform defines the scope and role for the service, and the defined scope and role through the API manager. can manage That is, when a user requests access to a service, after user authentication, whether the scope assigned to the service and the user's role allow access to the service is checked, and then the service is allowed to be used.

In a system based on a cloud platform that provides services after authentication in the above-described manner, as the services provided through the platform become more diverse and the number of users increases, the problem of system performance deterioration or the complexity of the process to process authentication increases. There are problems such as increasing and difficult to manage.

A technical problem to be solved through some embodiments is to provide a system, apparatus, and method capable of reducing degradation in response performance caused by authentication of users and services when accessing services provided through a platform. .

In addition, another technical problem to be solved through some embodiments is to provide a system, apparatus, and method capable of reducing complexity in terms of management due to an increase in users and services.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

In order to solve the above technical problem, a method for providing a service using a cloud platform according to an embodiment includes, when registering an application program interface for a service in a service gateway, an authentication information provider of the cloud platform to obtain a pass ticket ID. generating, and when the user is authenticated for the service through the user's login process, issuing a user authentication token for the user by the authentication information provider, and applying for use registration to use the service If received, the authentication information provider issues a service token generated using the passticket ID for the service, and the service gateway receives a call to the application program interface, a user authentication token, and a service token. In this case, verifying whether the received service token is valid as the issued service token through the authentication information provider, and if the received service token is valid, the service gateway makes the call to a first service provider; and transferring the received user authentication token and the received service token.

In addition, according to another embodiment, in the verifying step, when the call is received, the validity of the received service token is verified through a key management system of the authentication information provider that manages the issued service token. It can be characterized by doing.

In addition, according to another embodiment, the service providing method, when the first service provider receives the call, allows the first service provider to verify the validity of the received user authentication token to the authentication information provider. When the requesting step and verification of validity of the received user authentication token by the authentication information provider are completed, the first service provider calls the application program interface, and the service gateway calls the application program interface result. The step of forwarding the call to the terminal that generated the call may be further included.

In addition, according to another embodiment, requesting verification of the validity of the received user authentication token may include the received user authentication token through an identity and access manager of the authentication information provider that manages the issued user authentication token. It may be characterized in that the validity of the user authentication token is verified.

Also, according to another embodiment, the use registration application may be any one of purchase of the service, selection of the purchased service, and request for participation in a project set to develop the service.

In addition, according to another embodiment, the issuing of the service token may include generating a secret key corresponding to the use registration application, and generating a message including the passticket ID and the secret key. and generating a signature using the passticket ID, the private key, and the message, and generating the service token composed of the message and the signature.

Further, according to another embodiment, the issuing of the service token may include issuing the service token in units of projects set for purchase of the service, selection of the purchased service, or development of the service. can be done with

In addition, according to another embodiment, the passticket ID may include a resource identifier of a secret key for the service or project, a key name for the secret key, and a validity period for the service or project. .

In addition, according to another embodiment, the service providing method further includes receiving a product ID by the authentication information provider and generating the resource identifier using the product ID when generating the passticket ID. can include

Further, according to another embodiment, when a call to an additional application program interface provided by a second service provider is generated in order for the first service provider to process the call, the first service provider may send the additional application program interface to the additional application program interface. The method may further include calling an application program interface and transferring the received user authentication token and the received service token to the second service provider.

In order to solve the technical problem, a service providing system using a cloud platform allocates a pass ticket ID for identifying the service at the time of registration of an application program interface that provides a service through the cloud platform, and assigns the pass ticket ID to the pass ticket ID. A service token is generated in response to a request for registration of use of the service using the service token, and when the user is authenticated through the user's login process, a user authentication token for the user is generated, and the service token and the user authentication token are generated. An authentication information provider that performs validity verification on, and manages the application program interface, and when a call to the application program interface, a user authentication token, and a service token are received, the validity of the service token is checked through the authentication information provider. If the service token is valid after being verified, upon receipt of the call, the service gateway that delivers the user authentication token and the service token to the service provider providing the application program interface, and a catalog registration request, the corresponding catalog registration request is received. and a catalog service provider that registers a catalog, receives a passticket ID from the authentication information provider, and registers the application program interface with the service gateway.

A computer program recorded on a non-transitory computer readable medium for solving the technical problem is an application program for a service to a service gateway when instructions of the computer program are executed by a processor of a computing device. When registering the interface, the authentication information provider of the cloud platform generates a pass ticket ID, and when the user is authenticated for the service through the user's log-in process, the authentication information provider is the user for the user. issuing an authentication token, and when a use registration application for the service is received, issuing, by the authentication information provider, a service token generated by using the passticket ID for the service; When the call to the application program interface, the user authentication token and the service token are received, verifying whether the received service token is valid as the issued service token through the authentication information provider and the received service token If this is valid, an operation including transferring the call, the received user authentication token, and the received service token to the first service provider by the service gateway is performed.

1 is a diagram simply showing the structure of a service providing system.
2 is a diagram illustrating the structure of a service providing system according to some embodiments.
3 is a diagram illustrating a process of registering a new service in a service providing system according to some embodiments.
4 is a diagram illustrating a process of calling an API to develop a service, according to some embodiments.
5 is a diagram illustrating a process of calling an API to provide a service to a user, in accordance with some implementations.
6 is a diagram illustrating an example for explaining a structure of calling an API of a service according to a method of accessing a service from an application by registering a client ID.
7 is a diagram illustrating an example for explaining a structure of calling an API of a service using a service token according to some embodiments.
8 is a diagram for explaining a process of generating a service token according to some embodiments.
9 is a diagram illustrating a process when an API call occurs between a plurality of services according to some other embodiments.
10 is a diagram for explaining a process performed by a service providing system to provide a service to a user according to some embodiments.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention, and methods for achieving them, will become clear with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms, only the present embodiments make the disclosure of the present invention complete, and the common knowledge in the art to which the present invention belongs It is provided to fully inform the holder of the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numbers designate like elements throughout the specification.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used in a meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless explicitly specifically defined. Terminology used herein is for describing the embodiments and is not intended to limit the present invention. In this specification, singular forms also include plural forms unless specifically stated otherwise in a phrase.

Hereinafter, some embodiments of the present invention will be described with reference to the drawings.

1 is a diagram simply showing the structure of a service providing system.

The service providing system 100 may include a catalog service provider 110 , an authentication server 120 and a service gateway 130 . Here, according to some embodiments, the catalog service provider 110, the authentication server 120, and the service gateway 130 may each be configured as independent servers. Or, according to some other embodiments, the catalog service provider 110, the authentication server 120, and the service gateway 130 are each in the form of a virtual machine (Virtual Machine), a single unit having one or more processors and one or more memories. It may also consist of a device.

Upon receiving the catalog registration request, the catalog service provider 110 may register a catalog corresponding to the catalog registration request. Here, the catalog registration request means a request to register a service to be provided in the catalog through a platform configured by the service providing system. Also, registering a catalog means registering in a catalog service so that registered services can be inquired, purchased, and used.

Upon receiving a catalog registration request, the catalog service provider 110 according to some embodiments may receive a passport ID for a service to be registered from the authentication server 120 . The catalog service provider 110 may register an API of a service in a service gateway to manage a corresponding service based on the provided passticket ID.

The authentication server 120 may generate a user authentication token for authenticating a user and a service token for authenticating a service according to a received request. In addition, the authentication server 120 may verify the validity of the user authentication token or service token according to a request from other components or external components of the service providing system 100 .

When a user wants to use a service provided through the service providing system 100 , the service can be accessed through the service gateway 130 . When receiving a call to an API registered in the service gateway 130, the service gateway 130 may check whether a user authentication token and a service token are received along with the call. When the user authentication token and the service token are received along with the call, the service gateway 130 may request validation of the validity of the service token from the authentication server 120 . When it is confirmed that the validity of the service token has been verified by the authentication server 120, the service gateway 130 provides the service provider providing the service including the API to be called based on the verification result of the service token to the API. You can pass calls, user authentication tokens and service tokens.

Upon receiving the user authentication token and the service token, the service provider requests the authentication server 120 to verify validity of the user authentication token, and determines whether or not to perform the called API according to a result of verifying the user authentication token. Therefore, according to some embodiments, whenever the service gateway 130 calls the API on behalf of the user, whether or not the API can be accessed according to the user's role along with the assigned scope for the API. There is no need to designate realms and user roles according to the API of the service to manage, and there is no need to verify each time a user accesses the API, so service response performance does not deteriorate even if complexity increases.

2 is a diagram illustrating the structure of a service providing system according to some embodiments.

According to some embodiments, the service providing system 100 may interact with a user (eg, an end user, a developer, an analyst, or a partner) through the service interface 200 . The service interface 200 means an environment for accessing the service providing system 100 to develop a service to be provided, to register a developed service, or to inquire and purchase a registered service. For example, the service interface 200 may be a user portal 201 , a developer portal 202 , or a marketplace 203 distributing services. Alternatively, the service interface 200 may be set as a developer's developer ID environment or may be a command line based interface client. Alternatively, the service interface 200 may be an integrated development environment (IDE), but is not limited thereto. The service interface 200, the catalog service provider 110, the authentication server 120, the service gateway 130, and the service provider 300 may be configured as separate hardware devices, such as independent servers, but in the embodiment Therefore, it may be configured in one hardware device using a virtual machine.

When a user logs in to the service providing system 100 through the service interface 200, the authentication server 120 may authenticate the user, and upon receiving a request for validating the validity of the token, the user authentication token or service token validity can be verified. According to some embodiments, the authentication server includes an identity provider (IdP) 121, a key management system 126, and a role-based access control (RBAC) server 127. can include Depending on the embodiment, the key management system 126 and the RBAC server 127 may be included in the authentication information provider 121 or integrally configured with the authentication information provider 121 . The authentication information provider 121 manages the authentication information provider UI web application server (IDP UI WAS) 122 to perform account management, integrated login, etc. of the authentication information provider, user authentication tokens, and validates the user authentication tokens. It may include an identity and access manager (IAM) 123, an STS server 124 providing a security token service, and a Multi-Factor Authentication (MFA) server 125.

The IAM 123 of the authentication information provider 121 may manage and verify a user authentication token for authenticating a user. According to some embodiments, the authentication information provider 121 may perform user authentication based on OAuth 2.0 and Security Assertion Markup Language (SAML). However, it is not limited to this. The IAM 123 may assign a role to a user and grant access to a service to the corresponding user.

In addition, the key management system 126 separately issues a service token distinct from the user authentication token using the pass ticket ID and secret key allocated by the key management system 126, and authenticates the service using the service token. can be performed. The catalog service provider 110 may include a catalog manager 111 that manages catalog services and a catalog service engine 112 that provides catalog services. When receiving a registration request or use request for a catalog, the catalog manager 111 may determine whether to approve the registration request or use request. When the catalog manager 111 approves the catalog registration request, a catalog corresponding to the registration request may be registered in the catalog service engine 112 . In this case, the catalog service engine 112 receives a pass ticket ID for identifying the service to be registered as a product through the key management system 126, and sends an API corresponding to the registration request to the API manager of the service gateway 130 ( 131) can be registered.

Also, according to some embodiments, the RBAC server 125 may issue a service token for each project to develop a service to be provided and verify the service token when requesting a service. When a user subscribes to the service providing system 100 through the service interface 200, a user ID for identifying the user is assigned to each user. In addition, when a project for developing a service is set through the service interface 200, a project ID for identifying the project may be allocated for each project. In order to issue and verify service tokens on a project-by-project basis, the RBAC server 125 includes a project member table that maps a project ID of a project and a user ID of a user registered in the project, and a project ID and a service token to be issued to the project. You can manage a passticket table that maps passticket IDs for services. In addition, the RBAC server 125 may manage authority information according to user roles for authority rights of users participating in the project.

The service gateway 130 according to some embodiments may include an API manager 131 that registers and manages service APIs and an internal gateway 132 that performs routing, load balancing, discovery, or circuit breaker functions. A user who wants to use a service using the service interface 200 may access a service provided by the service provider 300 through the service gateway 130 .

The service gateway 130 may receive an API call for an API of a service that a user wants to use from the service interface 200 together with a user authentication token for user authentication and a service token for service authentication. Here, the service gateway 130 may verify the signature of the service token by making a request to the key management system 126 . The service gateway 130 successfully verifies the service token, checks whether or not there is a user authentication token received along with the API call, and provides a service using the user authentication token and the service token through the called API (300). ) can be forwarded to

3 is a diagram illustrating a process of registering a new service in a service providing system according to some embodiments.

First, when login is performed with a developer ID through the service interface 200 in step S310, the catalog manager 111 may perform user authentication through the authentication information provider 121 in step S320.

After login and user authentication are completed, in step S330, the catalog manager 111 may receive a catalog registration request for registering the developed service in the catalog through the logged-in user account. The catalog manager 111 may determine whether to approve the received catalog registration request.

When the received catalog registration request is approved, the catalog manager 111 may register a catalog in the catalog service engine 112 in response to the catalog registration request in step S340. Here, registering a catalog may mean registering to inquire and purchase a service through the catalog.

Then, in step S350, if the service corresponding to the registration request is a new service not registered in the service gateway 130, the catalog service engine 112 requests the authentication information provider 121 for a passticket ID for the service. can Thereafter, according to the request received from the catalog service engine 112 in step S360, the authentication information provider 121 may issue a pass ticket ID.

Then, in step S370, the catalog service engine 112 may register the API corresponding to the registration request with the service gateway 130. That is, when registering a new service, the service providing system 100 may issue a pass ticket ID for the service and register a corresponding API in the service gateway 130 .

4 is a diagram illustrating a process of calling an API to develop a service, according to some embodiments.

First, when login is performed with a developer ID through the service interface 200 in step S410, the catalog manager 111 may perform user authentication through the authentication information provider 121 in step S420.

Thereafter, the catalog manager 111 may receive a service use registration application for using the service in step S430 and determine whether to approve the service use registration application. Here, the service use registration application may be any one of a purchase process of purchasing a service through the service interface 200, a process of inquiring and selecting a purchased service, and a request for participation in a project set to develop a service. When the service use registration application is approved, the catalog manager 111 may transmit the service use registration application to the catalog service engine 112 in step S440.

Thereafter, a service token for a service corresponding to the service use registration application may be requested from the authentication information provider 121 in step S450. Upon receiving the request for the service token, the authentication information provider 121 may issue the service token using the passticket ID and secret key for the service in step S460. The catalog service engine 112 that has been issued a service token may transfer the issued service token to the catalog manager 111 . Here, the manager who has been issued the service token can check the issued service token through the service interface 200 .

Then, when logging in with the developer account for which the service token was issued in step S480, user authentication is performed through the authentication information provider 121, and the user authentication token can be issued from the authentication information provider 121 to the service interface 200. there is.

Thereafter, the developer may transfer the API call to the service gateway 130 through the service interface 200 along with the issued user authentication token and service token. In addition, a developer may develop a service using a user authentication token and a service token issued through the service interface 200 and register it in the service gateway 130 .

5 is a diagram illustrating a process of calling an API to provide a service to a user, in accordance with some implementations.

First, in step S510, a user who wants to use a service may attempt to log in with a user ID through the service interface 200. Thereafter, in step S520, the user may be authenticated through the authentication information provider 121.

After performing authentication on the user in step S520, the authentication information provider 121 may issue a user authentication token for the user using the IAM 123 in step S530. In addition, although not separately shown in FIG. 5 , when a service is purchased by a corresponding user or a service purchased through the service interface 200 is selected, the authentication information provider 121 provides the key management system 126 ) through which a service token for a corresponding service can be issued to the service interface 200 .

Subsequently, when a service request for using a service is received through the service interface 200 in step S540, the service interface 200 sends an API call to the service gateway 130 to call the API of the requested service in step S550. can be forwarded to Here, the service interface 200 may deliver an issued user authentication token and a service token for a service together when delivering an API call.

Upon receiving the API call, the service gateway 130 may request verification of validity of the service token from the authentication information provider 121 in step S560. Here, the authentication information provider 121 may use the key management system 126 to verify whether the received service token is valid for the previously issued service token. Here, the service gateway 130 may only check whether or not there is a user authentication token received along with the received API call.

When verification of the service token is completed and the user authentication token received along with the API call exists, the service gateway 130 transmits the corresponding API call to the service provider along with the received service token and the received user authentication token in step S570. (300).

Then, in step S580, the service provider 300 may request verification of the received user authentication token from the authentication information provider 121. Here, the authentication information provider 121 may verify whether the received user authentication token is valid for the user authentication token issued through the IAM 123 .

According to some other embodiments, when a service corresponding to a service request is developed using a service token as in the process shown in FIG. 4 , it is necessary to perform verification on the service token as well. Accordingly, when the service corresponding to the service request is developed using the service token, the service provider 300 may further request verification of the service token from the authentication information provider 121 in step S580.

When the authentication information provider 121 transfers the verification result of the user authentication token to the service provider 300, the service provider 300 may execute an API corresponding to the API call according to the verification result in step S590. That is, when the validity of the user authentication token is verified, the service provider 300 executes the API corresponding to the API call and transmits the result of executing the API to the API call in step S595 through the service gateway 130 to the service interface. (200).

6 is a diagram illustrating an example for explaining a structure of calling an API of a service according to a method of accessing a service from an application by registering a client ID.

In order to call the API of the service provided through the cloud, the client ID can be registered based on the OAuth 2.0 protocol, and the application can access the service. In this case, a structure for calling an API of a service may be configured as shown in FIG. 6 as an example.

First, in step S601, the service gateway 130 may receive a call request for /read of the first service provided by the service provider 300. Step S601 may be performed after user authentication is completed through a login process or the like. In this case, in step S602, the service gateway 130 may check the scope of the API for /read in the API store 133 of the APIs registered in the service gateway 130.

After confirming that the scope of the API for /read is news_read, the service gateway 130 determines the scope for news_read and the role of the authenticated user and the role of the user who can access the scope of the API in step S603. Confirmation of can be requested to the authentication information provider 121 .

Thereafter, based on the result of confirmation through the authentication information provider 121, the service gateway 130 grants access to the API according to the result of confirming the role of the user and the area of the API for /read of the first service in step S605. can do. In order to determine whether access to the API is allowed through the method shown in FIG. 6, after designating the API area for /read of the first service and the role of the user at the time of registering the API in the service gateway, the service gateway ( 130) may request /read of the first service from the service provider 300 in step S606 according to the designated area and role. Thereafter, the service gateway 130 may receive a result of requesting /read from the service provider 300 and output the result in step S607 as a response to the request received in step S601.

However, as shown in FIG. 6 , when a client ID is registered and used without using a service token, an API area according to a user's role must be defined and managed in order to access a service API. In addition, since a user's role and area must be specified and registered for each service, and verification must be performed each time an API is accessed, response performance may deteriorate as the number of calls increases.

Alternatively, the service providing system 100 may grant an application credential that can be used repeatedly after being created once through a service account in units of projects and used when calling an API.

However, in this case, whenever the API is called, the application credential must be transmitted to the authentication server 120 to receive and use the token. Also, in this case, API areas must be defined and managed according to the user's role in order to access the API of the service, designate and register the user's role and area for each service, and verify each time they want to access the API. As the number of calls increases, response performance may deteriorate.

7 is a diagram illustrating an example for explaining a structure of calling an API of a service using a service token according to some embodiments.

According to some embodiments, when a user authentication token and a service token are separately issued and used, authentication may be performed with the structure shown in FIG. 7 . First, after the user logs in, in step S701, the service gateway 130 may receive a request for a call to /write of the first service provided by the service provider 300. In this case, the API manager 131 of the service gateway 130 may check information about the first service registered in the API store 133 of the service gateway 130 . Referring to FIG. 7 , it is possible to check the service ID and passticket ID for the first service in the API store 133, and it can be confirmed that APIs registered for the first service are /read and /write.

Thereafter, in step S703, the authentication information provider may be requested to verify the service token along with the verified passticket ID for the first service. When verification of the service token is completed through the authentication information provider 121, the service gateway 130 is checked in step S704 and the service provider 300 in step S705 for /write, an API registered for the first service. You can pass a service token and user authentication token along with a request to /write.

Thereafter, the service provider 300 may request the authentication information provider 121 to verify the received user authentication token along with the request for /write in step S706. Thereafter, the service provider 300 may perform /write of the first service according to the verification result, and deliver the result of performing /write to the service gateway 130 in step S707. The service gateway 130 receiving the result of performing /write may output the result of performing /write as a response to the request received in step S701. According to some embodiments, service IDs may correspond to passticket IDs on a one-to-one basis. Also, a plurality of different service tokens may be issued based on one passticket ID. For example, a plurality of service tokens may be issued by specifying a usable period based on one pass ticket ID. For another example, a service token may be issued by specifying a time period in which a service can be used for each user ID. For another example, a valid service token may be issued for a period during which one login is maintained, that is, from a time when a user logs in to a time when a user logs out. Also, according to some embodiments, a plurality of user authentication tokens may be issued based on one user ID. For example, a plurality of user authentication tokens may be issued that designate valid time zones of the day differently for one user ID. For another example, a user authentication token valid for one user ID from the time the user logs in to the time the user logs out may be issued.

That is, when authentication is performed with the structure shown in FIG. 7 using a service token, the service gateway 130 does not need to designate an API realm and a user role each time, thereby reducing unnecessary resource use. can Accordingly, even if the number of API calls increases, response performance can be prevented from deteriorating.

8 is a diagram for explaining a process of generating a service token according to some embodiments.

First, when the service providing system 100 receives a service registration request in step S810, it may determine whether the service requested to be registered is a new service that has not been registered with the service gateway 130 (S820). . As a result of determination in step S820, if the service requested for registration is a new service, the authentication server 120 may generate a passticket ID. According to some embodiments, the authentication server 120 may generate a pass ticket ID using a resource identifier for a secret key of a service or project, a key name for the secret key, and an expiration date through the key management system 126. there is. Here, the validity period may be a validity period of purchasing a service or a validity period of a project for service development. For example, as shown in Table 1 below, the authentication server 120 may generate a pass ticket ID (ticketID) using a resource identifier (KeyURI), a key name (keyName), and a project validity period (ProjectPeriod).

KeyURI: /SDS/Dept/Project1, keyName: Project1-PassTicket,
ProjectPeriod = 1 year
ticketID = createServiceKey(keyName, keyURI, AES256, ProjectPeriod)

After the service is registered through steps S810 to S830, when the service providing system 100 receives a use registration application for using the registered service in step S840, the authentication server 120 determines the corresponding service in step S850. A secret key can be generated according to the pass ticket ID. According to some embodiments, the authentication server 120 may generate a secret key by setting a duration for the authentication key. For example, if the maintenance period is set to 15 minutes, the corresponding secret key can be used for 15 minutes, and if the maintenance period is set to 0, a fixed secret key without change can be generated. An example of a syntax for generating a secret key (Passkey) based on a ticket ID (ticketID) and a duration (duration) may be configured as shown in Table 2.

Passkey = getServiceKey(ticket id, duration)

Then, in step S860, the authentication server 120 may generate a ticket message using the pass ticket ID and the secret key. According to some embodiments, the ticket message may include service-related information such as a pass ticket ID, a project ID, a secret key, and a maintenance period.

Then, in step S870, the authentication server 120 may generate a signature for the ticket message to verify the service token. Here, the authentication server 120 may generate a signature using a pass ticket ID, a secret key, and a ticket message through the key management system 126 . For example, as shown in Table 3 below, the key management system 126 may generate a signature using a pass ticket ID (ticketID), a secret key (Passkey), and a ticket message (ticket message).

Signature = CreateSignature (ticket id, passkey, ticket message)

Thereafter, the authentication server 120 may generate a service token including a ticket message and a signature in step S880.

ServiceToken = TicketMesasage+Signature

According to some embodiments, the process shown in FIG. 8 may be performed using the key management system 126, in which case the API manager 131 or the service provider 300 provides service through the key management system 126. Token verification can be performed.

9 is a diagram illustrating a process when an API call occurs between a plurality of services according to some other embodiments.

According to some embodiments, API calls may occur between a plurality of services. For example, in the process of executing an API provided by the first service 300-1, there may be a case in which an API provided by the second service 300-2 is called.

Here, steps S910 to S990 may be performed similarly to steps S510 to S590 of FIG. 5 . When the first service 300-1 calls the API of the second service 300-2 in the process of executing the API in step S990, the first service 300-1 calls the API of the second service 300-2 in step S991. The API call of -2) and the service token and user authentication token received in step S970 may be delivered to the second service 300-2.

Thereafter, in step S992, the second service 300-2 may request verification of the user authentication token from the authentication information provider 121. Thereafter, in step S993, the second service 300-2 executes the API according to the verification result, and then in step S994, the API call result of the second service 300-2 may be delivered to the first service 300-1. there is.

Then, after the first service 300-1 finishes executing the API using the API call result of the second service 300-2, the API call result of the first service 300-1 is sent to the service interface (S995). 200) can be passed on.

10 is a diagram for explaining a process performed by a service providing system to provide a service to a user according to some embodiments.

First, in step S1010, the service providing system 100 may register a new service. Here, the service providing system 100 may register a developed service, provide a project to develop a service to be provided, and register the developed service.

Thereafter, in step S1020, the service providing system 100 may issue a user authentication token to the user after the user is authenticated by logging into the service providing system 100.

Then, in step S1030, the service providing system 100 may process a use registration application for the registered service. Here, application for use registration may mean performing any one of purchasing a registered service through the service interface 200, selecting a purchased service, and participating in a project set to develop the service. In step S1030, the service providing system 100 may issue a service token for authentication of a registered service by processing a use registration application.

Then, in step S1040, the service providing system 100 may receive a user authentication token and a service token together with an API call for using the service. Then, in step S1050, the service providing system 100 may request the authentication server 120 to verify validity of the service token. The authentication server 120 may perform verification of validity of the service token using the key management system 126 .

When the service token is verified, the service providing system 100 may transfer the user authentication token and the service token to the service provider 300 providing the service along with an API call in step S1060.

Thereafter, the service provider 300 receiving the user authentication token and the service token along with the API call may request verification of validity of the user authentication token to the authentication server 120 of the service providing system 100 . The authentication server 120 may use the IAM 123 to verify the validity of the user authentication token.

Thereafter, when the user authentication token is verified, the service provider 300 may perform the API called in step S1080 and deliver the API performance result to the service providing system 100 .

The methods according to the embodiments of the present invention described so far can be performed by executing a computer program implemented as a computer readable code. The computer program may be transmitted from the first computing device to the second computing device through a network such as the Internet, installed in the second computing device, and thus used in the second computing device. The first computing device and the second computing device include both a server device, a physical server belonging to a server pool for a cloud service, and a fixed computing device such as a desktop PC.

The computer program may be stored in a recording medium such as a DVD-ROM or a flash memory device.

Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art to which the present invention pertains can be implemented in other specific forms without changing the technical spirit or essential features of the present invention. can understand that Therefore, the embodiments described above should be understood as illustrative in all respects and not limiting.

Claims (12)

In the method of providing a service using a cloud platform,
generating a passticket ID by an authentication information provider of the cloud platform when registering an application program interface for a service in a service gateway;
issuing, by the authentication information provider, a user authentication token for the user when the user is authenticated for the service through the user's login process;
issuing, by the authentication information provider, a service token generated by using the passticket ID for the service when a use registration application for using the service is received;
when the service gateway receives a call to the application program interface, a user authentication token, and a service token, verifying whether the received service token is valid as the issued service token through the authentication information provider; and
If the received service token is valid, the service gateway forwarding the call, the received user authentication token, and the received service token to a first service provider.
A method of providing services using a cloud platform. According to claim 1,
The verification step is
When the call is received, verifying the validity of the received service token through a key management system of the authentication information provider that manages the issued service token.
A method of providing services using a cloud platform. According to claim 1,
requesting, by the first service provider, verification of validity of the received user authentication token to the authentication information provider, when the first service provider receives the call; and
When verification of validity of the received user authentication token is completed by the authentication information provider, the first service provider calls the application program interface, and transmits the calling result of the application program interface through the service gateway. Further comprising the step of delivering to the terminal that generated the,
A method of providing services using a cloud platform. According to claim 3,
Requesting verification of the validity of the received user authentication token,
verifying the validity of the received user authentication token through an identity and access manager of the authentication information provider managing the issued user authentication token;
A method of providing services using a cloud platform. According to claim 1,
The application for registration of use,
Any one of purchasing the service, selecting the purchased service, and requesting participation in a project set to develop the service,
A method of providing services using a cloud platform. According to claim 1,
The step of issuing the service token,
generating a secret key corresponding to the use registration application;
generating a message including the pass ticket ID and the secret key;
generating a signature using the pass ticket ID, the secret key, and the message;
Generating the service token composed of the message and the signature,
A method of providing services using a cloud platform. According to claim 1,
The step of issuing the service token,
Issuing the service token in units of projects set for purchase of the service, selection of the purchased service, or development of the service,
A method of providing services using a cloud platform. According to claim 7,
The pass ticket ID is,
Including the resource identifier of the secret key for the service or the project, the key name for the secret key, and the validity period for the service or the project,
A method of providing services using a cloud platform. According to claim 8,
receiving a product ID by the authentication information provider; and
Further comprising generating the resource identifier using the product ID when generating the passticket ID,
A method of providing services using a cloud platform. According to claim 1,
When the first service provider calls an additional application program interface provided by a second service provider to process the call, the first service provider calls the additional application program interface, the received Further comprising passing the user authentication token and the received service token to the second service provider.
A method of providing services using a cloud platform. In a service providing system using a cloud platform,
A passticket ID identifying the service is allocated at the time of registration of an application program interface that provides services through the cloud platform, and a service token is generated in response to a request for registration of use of the service using the passticket ID. and an authentication information provider generating a user authentication token for the user when the user is authenticated through the user's login process and validating the service token and the user authentication token;
The application program manages the application program interface, and when a call to the application program interface, a user authentication token, and a service token are received, the validity of the service token is verified through the authentication information provider, and the service token is valid. a service gateway that forwards the call, the user authentication token, and the service token to a service provider providing an interface; and
When receiving a catalog registration request, a catalog service provider registers a catalog corresponding to the catalog registration request, receives a passticket ID from the authentication information provider, and registers the application program interface with the service gateway.
A service delivery system using a cloud platform. As a computer program recorded on a non-transitory computer readable medium, when the instructions of the computer program are executed by a processor of a computing device,
generating a pass ticket ID by an authentication information provider of the cloud platform when registering an application program interface for a service using a cloud platform with a service gateway;
issuing, by the authentication information provider, a user authentication token for the user when the user is authenticated for the service through the user's login process;
issuing, by the authentication information provider, a service token generated by using the passticket ID for the service when a use registration application for the service is received;
when the service gateway receives a call to the application program interface, a user authentication token, and a service token, verifying whether the received service token is valid as the issued service token through the authentication information provider; and
Characterized in that, if the received service token is valid, an operation comprising transferring the call, the received user authentication token, and the received service token to a first service provider by the service gateway is performed.
computer program.

Images