KR102190268B1 - A secure interoperable access control framework for heterogeneous iot platform - Google Patents

Abstract

A security interoperability support access control framework for heterogeneous IoT platforms is disclosed. An interoperability support access control method according to an embodiment includes the steps of: providing a security interoperability support access control framework virtualizing a layer for access control; And supporting interoperability between heterogeneous IoT platforms through an access control framework supporting security interoperability based on the virtualized layer.

Description

Security interoperability support access control framework for heterogeneous IoT platforms {A SECURE INTEROPERABLE ACCESS CONTROL FRAMEWORK FOR HETEROGENEOUS IOT PLATFORM}

The description below relates to access control technology supporting security interoperability for heterogeneous IoT platforms.

With the Internet of Things (IoT) in the spotlight as an important technology in the future, IoT platforms such as Watson IoT, IoTivity, and ARTIK are being developed, and an access control (authentication and authorization) framework to protect resources within each platform. It is also being developed individually. However, access control frameworks are developed under the assumption that they are used in each IoT platform, and interoperability between heterogeneous IoT platforms is not considered. For example, currently, if you want to use resources that exist in five IoT platforms, there is a problem that you must use the resources after each authentication and authorization process required by the platforms. This is one of the important issues to be resolved in the future in the IoT environment where hyper-connectivity is emphasized.

By virtualizing the layer for access control, it is possible to provide an access control framework that supports security interoperability in common to various IoT platforms.

Security interoperability support Interoperability between heterogeneous IoT platforms can be supported through an access control framework.

The interoperability support access control method includes: providing a security interoperability support access control framework by virtualizing a layer for access control; And supporting interoperability between heterogeneous IoT platforms through an access control framework supporting security interoperability based on the virtualized layer.

In the providing of the security interoperability support access control framework, a security interoperability support access control framework in which layers for access control of authentication, authorization, and auditing are virtualized as one layer. It may include providing to the IoT server platform.

The step of supporting interoperability may include supporting interoperability based on an interoperable access token (IAT) in the IoT server platform.

The step of supporting interoperability may include issuing an interoperability access token (IAT) based on Multiple Clients' Credentials (MCC) through the secure interoperability support access control framework.

The step of supporting interoperability may include requesting an interoperability access token (IAT) having the authority to access the plurality of IoT server platforms using the requester's credentials registered in the plurality of IoT server platforms from the requester. It may include.

In the step of supporting the interoperability, the first IoT server platform verifies the credential of the first IoT server platform among the credentials transmitted from the requester, and the first IoT server platform transmits it from the requestor. As the credential verification request is transmitted to the second IoT server platform among the credentials, the second IoT server platform verifies the credentials transmitted from the first IoT server platform to the first IoT server platform. It may include the step of transmitting a credential verification result that has performed the credential verification.

The step of supporting interoperability may include generating an interoperable access token (IAT) having a global access range accessible to the first IoT server platform and the second IoT server platform from the first IoT server platform. It may include steps.

The step of supporting interoperability may include limiting an area accessible to a resource according to a credential verification result in the first IoT server platform or the second IoT server platform.

The step of supporting interoperability may include an interoperable access token accessible to one or more IoT server platforms of the first IoT server platform or the second IoT server platform to the requester from the first IoT server platform. (IAT) is issued, the issued interoperable access token (IAT) is transmitted to the requester, and the second interoperable access token (IAT) issued from the first IoT server platform is issued from the requestor. It may include the step of accessing the IoT server platform.

The step of supporting interoperability is based on ACMD (Authorization Code for Multiple Domains) through an access control framework that supports security interoperability virtualized through A3 Framework as a Service (A3FaaS) and deployed on each IoT server platform. As such, it may include issuing an interoperable access token (IAT).

In the step of supporting interoperability, as resources for access from a client are specified and issuance of an interoperable access token (IAT) is requested, the permission of resource owners is obtained in order to obtain permission for the resource that has requested access, and , Transmits the obtained permission to the A3 server, issues an authorization code to the client through a verification result of verifying the permission transmitted from the client in the A3 server, and issues an authorization code issued from the A3 in the client It may include the step of delivering the A3 server again, verifying the authorization code received from the client in the A3 server, and issuing an interoperable access token (IAT) to the client.

The step of supporting interoperability is an interoperable access token (IAT) based on IMD (Implicit for Multiple Domains) through a security interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform. It may include the step of issuing.

In the step of supporting the interoperability, the access range of the requested resource and the redirection URI to be issued with the interoperability access token (IAT) are transmitted from the client, and thus the authorization for the access range of the requested resource is obtained through a login process. In order to do so, obtain permission from resource owners, transfer the permission to the A3 server, and verify the resource requested from the client in the A3 server, the interoperability policy of the domain in which the requested resource is located, and the requested resource credential After that, it may include the step of delivering an interoperable access token (IAT) to the client.

The step of supporting interoperability is an interoperability access token based on MROPC (Multiple Resource Owners' Password Credentials) through a security interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform. IAT) may be included.

In the step of supporting the interoperability, the credentials of the resource owners previously stored or the credentials of the resource owners for requesting the resource are received from the client, and the access range of the requested resource and the resource owner credential are transmitted to the A3 server. And issuing an interoperable access token (IAT) by verifying the access range of the resource requested from the client and the resource owner credential in the A3 server.

The step of supporting interoperability is based on MCC (Multiple Clients' Credentials) through a security interoperability support access control framework that is virtualized through A3 Framework as a Service (A3FaaS) and deployed on each IoT server platform. It may include issuing an interoperable access token (IAT).

In the step of supporting interoperability, the client transmits the credentials of clients related to the access range of the resource to the A3 server, verifies the client credentials transmitted from the A3 server, and updates the access range of the resource. It may include issuing an interoperable access token (IAT).

The control system for interoperability support access control includes: a framework providing unit that provides a security interoperability support access control framework by virtualizing a layer for access control; And an interoperability support unit supporting interoperability between heterogeneous IoT platforms through a security interoperability support access control framework based on the virtualized layer.

The security interoperability support access control framework that virtualizes the access control layer considering interoperability can provide security interoperability between heterogeneous IoT platforms.

Token management is easy because it is possible to access multiple domains using an interoperable access token.

IoT devices can minimize the performance burden required for the authentication and authorization process for interoperability by entrusting the authentication and authorization process to the IoT platform.

FIG. 1 is a diagram illustrating providing an access control framework supporting security interoperability by virtualizing a layer for access control in an embodiment.
FIG. 2 is a diagram illustrating an access control framework supporting security interoperability of a control system according to an embodiment.
3 is a flowchart illustrating an operation for access control supporting security interoperability between IoT server platforms in a control system according to an embodiment.
4 is another example of an access control framework supporting security interoperability of a control system according to an embodiment.
5 to 10 are various examples for explaining a method of issuing an IAT in a control system according to an embodiment.
11 is a block diagram illustrating a configuration of a control system according to an embodiment.
12 is a flowchart illustrating an access control method supporting security interoperability in a control system according to an embodiment.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

FIG. 1 is a diagram illustrating providing an access control framework supporting security interoperability by virtualizing a layer for access control in an embodiment.

In the access control framework considering interoperability, authentication, authorization, and audit layers are virtualized and can be collectively provided to the IoT platform. 1 shows an overview of the authentication, authorization, and auditing layers, and can be applied by extending the existing OAuth 2.0 standard in order to provide interoperable access control at the A3 (Authentication, Authorization, Auditing; A3) layer. Since the existing OAuth 2.0 standard does not define a clear authorization capability or token structure, if OAuth 2.0 is implemented in each IoT platform, the authorization server function and token structure are inevitably different. There is a problem of lack of operability. In the embodiment, authentication, authorization, and audit functions are virtualized into one layer, so that the core functions or the structure of tokens are the same, so that interoperability between heterogeneous IoT platforms may be supported.

In an embodiment, interoperation may be performed based on an interoperable access token (IAT). An access token issued based on the existing OAuth 2.0 has a limited access scope in one domain (eg, ARTIK IoT platform), but the IAT according to the embodiment has a plurality of domains (for example, , ARTIK and FIWARE IoT platform) can have a global access scope (global access scope). This simplifies the management of tokens (token creation, renewal, and destruction) because it is only necessary to manage a single token instead of a plurality of tokens, and interoperability between heterogeneous IoT platforms can be provided.

IoT devices with limited performance delegate the authentication and authorization process to the authentication and authorization layer of the IoT platform, thereby minimizing the performance burden required for the authentication and authorization process for interoperability.

FIG. 2 is a diagram illustrating an access control framework supporting security interoperability of a control system according to an embodiment.

An access control framework 200 supporting security interoperability may be provided to the IoT platform 100. In FIG. 2, the operation of the security interoperability support control framework that operates for one IoT platform will be described.

In general, resources of the IoT server platform are individually managed for each domain. The access right to resources of the IoT server platform can be verified based on the access token. In the OAuth standard, for issuing an access token, a user or client-related credential must be used or a resource owner's grant must be obtained.

Specifically, a requestor who wants to access the IoT server platform 100 may register user/client information in the security interoperability support access control framework 200 using an interface provided through a web server or the like (1 ). The security interoperability support access control framework 200 may authenticate and authorize the requester 210 through a process such as an authorization code specified in the OAuth 2.0 standard (2). The security interoperability support access control framework 200 may issue an access token (3). The security interoperability support access control framework 200 may terminate the session without issuing a token if the authentication and authorization process fails. A resource of the IoT server platform 100 may be requested with a token issued by the requestor (4). The security interoperability support access control framework 200 may verify the presented token while a resource is requested from the requester (5). Security interoperability support In the access control framework 200, it has been described as an example to verify whether or not to use a resource by verifying an access token, but additional authentication/authorization based on attributes such as a role. Procedures may be added. The security interoperability support access control framework 200 may search for resources of the IoT server platform 100 when the token is normally verified (6). When a resource requested from the requestor 210 exists in the IoT server platform 100, the security interoperability support access control framework 200 may deliver the requested resource to the requestor 210 (7).

3 is a flowchart illustrating an operation for access control supporting security interoperability between IoT server platforms in a control system according to an embodiment.

In FIG. 3, a security interoperability access control operation between a plurality of IoT server platforms will be described. In this case, an operation from issuing an interoperable access token (IAT) to requesting a resource to enable access to data or services provided by heterogeneous IoT server platforms will be described. For IAT issuance, the use of the Multiple Clients' Credentials (MCC) method, which extends the existing Client Credentials (CC), will be described as an example. When a requestor first requests IAT, credentials of several domains are transmitted, and communication between IoT server platforms can be made to verify the credentials.

First, the components constituting the control system will be described. The requester 210 refers to an IAT capable of accessing resources provided from a heterogeneous IoT server platform and a subject requesting a resource using the accessible IAT. IoT server platform A (first IoT server platform) 301 is a reliable IoT server platform, and IoT server platform A 301 and IoT server platform B 302 according to the requester's IAT issuance request. You can issue an IAT that is accessible to you. The IoT server platform B (the second IoT server platform) 302 is a reliable IoT server platform and can process a credential verification request from the IoT server platform A 301 and process resource requests. .

The security interoperability support access control modules 303 and 304 are security modules that provide authentication, authorization, and audit based on a virtualized security interoperability support access control framework. The security interoperability support access control modules 303 and 304 may perform access control (authentication and authorization) for a client who wants to access the server based on the extended OAuth 2.0 to protect the internal resources of the server. Authorization is basically performed on a token basis, but for flexibility and context-aware access control, an access control model such as ABAC can be additionally used. The databases 305 and 306 may store resources or credentials of the IoT server platform. Data stored in the databases 305 and 306 may be allowed access only to users/clients who have been properly authenticated and authorized by the security interoperability support access control modules 303 and 304.

The user/client registration process required to use OAuth 2.0 is the same as described in FIG. 2. In FIG. 3, an operation process between the IoT server platform A 301 and the IoT server platform B 302 will be described. The requester 210 may request an IAT having the authority to access at least one IoT server platform by using the requestor's credentials registered in at least one IoT server platform (1). For example, the requester 210 uses the credentials of the requestor registered in the IoT server platform A 301 and the IoT server platform B 302 to use the IoT server platform A 301 and the IoT server platform B ( 302) can request an IAT with access rights. In this case, the credentials may be hashed to maintain confidentiality. Unlike the access tokens used in the existing OAuth standard, IAT can have a global access scope to access multiple domains. The global access scope may be set in the form of "access scope: {"domain information 1": "resource information 1", "domain information 2": "resource information 2"}. For example, the global access scope is " access scope: {"Domain A": "Resource 1", "Domain B": "Resource 2"}.

The IoT server platform A 301 may verify the credentials of the IoT server platform A 301 among the credentials received from the requester 210 (2). The IoT server platform A 301 may perform verification by hashing the credentials stored in the IoT server platform A 301 and comparing the hashed credentials transmitted from the requestor.

The IoT server platform A 301 cannot verify the credentials of the IoT server platform B 302 among the credentials transmitted from the requester, so the IoT server platform B ( Credential verification request may be transmitted to 302 (3). At this time, the credential delivered to the IoT server platform B 302 is the hashed credential delivered from the requestor 210.

The IoT server platform B 302 may verify the credentials transmitted from the IoT server platform A 301 (4). IoT server platform B (302) hashed the credentials stored in IoT server platform B (302) and hashed credentials transmitted from IoT server platform A (301), that is, hashing sent by the requestor. Verification can be performed by comparing it with the credential.

The IoT server platform B 302 may transmit a credential verification result that has performed the credential verification to the IoT server platform A 301 (5).

The IoT server platform A 301 may create an IAT having a global access scope accessible to the IoT server platform A 301 and the IoT server platform B 302 (6). In this case, an accessible area may be limited according to a credential verification result of the IoT server platform A 301 or the IoT server platform B 302. For example, if the credential verification of the IoT server platform B 302 fails, even if the requester 210 requests access to the IoT server platform B 302, the requester 210 ignores the request and the IoT server platform A 301 ), an IAT that can only be accessed can be created. If all of the credential verification fails, the IAT is not generated, but once the IAT is generated, the IoT server platform A (301) can share the hashed IAT used only for verification purposes to the IoT server platform B (302). have. Through this, the IoT server platform B 302 may verify the IAT (original IAT issued from the Internet of Things server platform A 301) transmitted when the requestor 210 requests a resource in the future. The hashed IAT is only used for verification of the (original) IAT that is delivered when a resource is requested, so even if an attacker steals it in the middle, he cannot access the resources of the IoT server platform A(301) or the IoT server platform B(302). Can't.

The IoT server platform A 301 may deliver the (original) IAT accessible to the IoT server platform A 301 and the IoT server platform B 302 to the requestor 210 (7). At this time, the IAT may be delivered using technologies such as DTLS and TLS to ensure confidentiality and integrity. IAT is basically a bearer type used in the OAuth standard, and it is different from general access tokens in that the scope of access is not one domain but multiple domains. If you use JWT and HMAC instead of Bearer token, you can also provide the integrity of the token itself.

The requester 210 may access the IoT server platform B 302 based on the original IAT issued from the IoT server platform A 301 (8). At this time, the used IAT is issued by the IoT server platform A 301, and access to the IoT server platform A 301 is also possible.

4 is another example of an access control framework supporting security interoperability of a control system according to an embodiment.

3 illustrates that IAT is issued based on the MCC, but the security interoperability support access control framework includes the Authorization Code for Multiple Domains (ACMD), which extends the Authorization Code, in addition to the MCC that extends Client Credentials, IAT issuance can be performed through Implicit for Multiple Domains (IMD) extended Implicit and Multiple Resource Owners' Password Credentials (MROPC) extended Resource Owner Password Credentials.

The security interoperability support access control framework 200 may be virtualized through the A3 Framework as a Service (A3FaaS) 400 and deployed on each IoT platform (eg, IoT server platform). Interoperability support access control functions such as IAT issuance of the access control framework are provided by the A3 server. In addition, the credentials (user/client credentials, tokens, etc.) used in the A3 server and the security policies (Domain Level Interoperability Policy (DL-IP) and Resource Level Interoperability Policy (RL-IP)) for interoperability support are respectively It can be stored and used in a database. Accordingly, various methods of IAT issuance method based on A3 will be described.

5 to 10 are various examples for explaining a method of issuing an IAT in a control system according to an embodiment.

Referring to FIG. 5, a method of issuing IAT based on ACMD (Authorization Code for Multiple Domains) will be described. ACMD refers to a method of issuing IAT using an authorization code issued through a user's login process. Clients can request IAT issuance by specifying the resources to access (1). A client can obtain permissions from resource owners (users who own a resource of the requested access range) to obtain permission for a resource requesting access, and can transmit permission to the A3 server (2). The A3 server can verify the permissions sent from the client, and issue an authorization code to the client through the verification result (3). The client can pass the authorization code issued from A3 back to the A3 server (4). The A3 server can issue IAT to the client after verifying the authorization code received from the client (5).

Specifically, referring to FIG. 6, the client 602 may initiate an ACMD for issuing IAT (1). The user agent 601 includes an access scope (for example, "access scope": {"domain A": "resource A", "domain B": "resource B"}) and a redirection URI requested by the client 602 Based on the IAT can be requested from the token endpoint of the A3 server 1 603 of domain A (2). At this time, the A3 servers of each domain are virtualized servers from the same A3FaaS, and any A3 server can provide the same interoperable access control function. Accordingly, the user agent 601 sends an IAT issuance request to the A3 server 1 603 of domain A, but can perform the same function by sending the IAT issuance request to the A3 server 2 604 of domain B.

The A3 server 1 603 of the domain A may redirect the user agent 601 requesting the IAT issuance to the login page (3). The user agent 601 may request a login from the resource owner (user) 600 of resources related to the access range requested from the client 602. The existing Authorization Code method requires only the credentials of a single resource owner, but since ACMD requires the credentials of resource owners corresponding to multiple domains, the login page can have multiple account input fields (4). The resource owner 600 may log in with the resource owner's account information (ID and password) and allow the client 602 to access the resource (5). For example, the resource owner 600 may allow access to the resource by inputting the resource owner's credentials. The user agent 601 may transfer the credentials input from the resource owner 600 to the A3 server 1 603 of domain A (6). Domain A's A3 server 1 (603) is an interoperable access policy (DL-IP and RL-IP) corresponding to domain A and resource A, and of the credentials received from the user agent 601, which corresponds to domain A. The dental can be verified (7). In addition, because the policy for resource B of domain B and the credential of the resource owner for resource B can be verified by the A3 server 2 604 of domain B, the A3 server 1 603 of domain A is A3 server 2 (604) may request a policy and credential verification for domain B and resource B (8).

Domain B's A3 server 2 (604) is the resource B requested from the client 602 and the domain B's interoperability policy (DL-IP and RL-IP) in which the resource B is located, and the resource owner's credential for resource B. Can be verified (9). Domain B's A3 server 2 (604) verifies the domain A's interoperability policies (DL-IP and RL-IP) in which resource B and resource B are located and the credentials of the resource owner for resource B. It can be delivered to the A3 server 1 (603) of (10). The A3 server 1 603 of domain A may update the access range requested by the client based on the resource policy and the credential verification result (11). For example, as it is determined that the credential verification result of domain B A3 server 2 604 has failed, domain A A3 server 1 603 can access only resource A excluding resource B. ": {"domain A": "resource A"}) can be modified. The A3 server 1 603 of the domain A can transmit the authorization code to the user agent 601 using the redirection URI, and the user agent 601 can deliver the authorization code issued from the domain A to the client 602. (12, 13). The client 602 may request IAT issuance to the A3 server 1 603 of domain A through the received authorization code (14). A3 server 1 603 of domain A may verify the authorization code and issue an IAT (15).

Referring to FIG. 7, a method of issuing IAT based on IMD (Implicit for Multiple Domains) will be described. The IMD is an authorization process that is a reduced process of ACMD of FIG. 6, and in the issuing stage of the authorization code, the IAT is issued immediately instead of the authorization code. Specifically, the client can initiate the IMD (1). The access range of the resource that the client wants to access and the redirection URI to receive IAT can be delivered together. The client may obtain permission from resource owners to obtain permission for the access range of the requested resource through the login process, and transfer the permission to the A3 server (2). The A3 server may transmit the IAT to the client after verifying the resource requested from the client, the interoperability policy of the domain in which the resource is located, and the credentials of the resource (3). In other words, the IAT issuing process based on the IMD is different from the IAT issuing process based on the ACMD, and the processes (12) and (13) of FIG. 6 are omitted, and the IAT is issued directly, not the authorization code.

Referring to FIG. 8, a method of issuing IAT based on Multiple Resource Owners' Password Credentials (MROPC) will be described. MROPC is a relatively simple method to ACMD or IMD, and there is no user agent or login process, and the IAT is issued by directly transmitting the resource owner's credentials. The client must already own the resource owner's credentials, or must receive the resource owner's credentials when requesting a resource (1). The client may transmit the MROPC request to the A3 server with the access range of the desired resource and the resource owner credential that can substitute the authority for the access range (2). Upon receiving the MROPC request, the A3 server can verify the access range and credentials of the resource requested from the client and issue IAT (3).

Specifically, referring to FIG. 9, the resource owner 1 901 of domain A and the resource owner 2 902 of domain B are the credentials of each resource owner (the credential of the resource owner 1 of the domain A, the resource of the domain B). Owner 2's credentials) can be passed to the client 602 (1, 2). The client 602 is the access scope of the resources desired to be accessed based on the resource owner's credentials (eg, "access scope": {"domain A": "resource A", "domain B": "resource B"} ) To start MROPC (3). A3 server 1 603 of domain A receiving a request from the client may verify the interoperation policies (DL-IP and RL-IP) corresponding to domain A and resource A, and resource owner credentials (4). Domain A's A3 server 1 (603) verifies the domain B's interoperability policy, which cannot be verified on its own, and the domain B's A3 server 2 (604) to verify the resource owner's credentials. The request can be sent (5). A3 server 2 604 of domain B may verify the interoperability security policy and resource owner credentials corresponding to domain B and resource B according to the verification request transmitted from the A3 server 1 603 of domain A ( 6). A3 server 2 604 of domain B may transmit an interoperation security policy for domain B and resource B and a verification result of performing resource owner credential verification to A3 server 1 603 of domain A (7 ). A3 server 1 603 of domain A can update the access range according to the interoperability security policy and credential verification result of A3 server 1 603 of domain A and A3 server 2 604 of domain B (8). ). For example, if domain A's A3 server 1 (603) fails to verify the interoperability policy or resource owner credentials of domain B's A3 server 2 (604), the access scope (e.g., For example, "access scope": {"domain A": "resource A"}) can be updated. The A3 server 1 603 of the domain A may generate an IAT based on the updated access range and transmit the generated IAT to the client 602 (9).

Referring to FIG. 10, a method of issuing IAT based on Multiple Clients' Credentials (MCC) will be described. MCC is similar to the MROPC method described above, but does not use the resource owner's credentials for issuing IAT, but uses the client credentials (ie, client ID and Secret). In order to obtain IAT, the credentials of clients related to the access range of resources can be transferred to the A3 server (1). The A3 server can issue an IAT after verifying the delivered client credentials, updating the access range appropriately (2).

As such, ACMD, IMD, MROPC, and MCC are used to issue IATs with a range of accessibility to heterogeneous domains, and each method is the Authorization Code, Implicit, Resource Owner Password Credentials, Client It depends on the environment or purpose in which the credentials are used.

FIG. 11 is a block diagram illustrating a configuration of a control system according to an embodiment, and FIG. 12 is a flowchart illustrating a security interoperability support access control method in a control system according to an embodiment.

The processor of the control system 1100 may include a framework providing unit 1110 and an interoperability support unit 1120. Components of such a processor may be expressions of different functions performed by the processor according to a control command provided by a program code stored in the control system 1100. The processor and components of the processor may control the control system to perform steps 1210 to 1220 included in the security interoperability support access control method of FIG. 12. In this case, the processor and the components of the processor may be implemented to execute an instruction according to the code of the operating system included in the memory and the code of at least one program.

The processor may load program code stored in a program file for a security interoperability support access control method into a memory. For example, when a program is executed in the control system, the processor may control the control system to load the program code from the program file into the memory under the control of the operating system. At this time, each of the processor and the framework providing unit 1110 and the interoperability support unit 1120 included in the processor executes a command of a corresponding part of the program code loaded into the memory to execute the subsequent steps 1210 to 1220. It may be different functional representations of the processor for.

In step 1210, the framework providing unit 1110 may provide an access control framework supporting security interoperability by virtualizing a layer for access control. The framework provider 1110 provides an access control framework that supports security interoperability by virtualizing a layer for access control of authentication, authorization, and auditing into one layer to the IoT server platform. can do.

In step 1220, the interoperability support unit 1120 may support interoperability between heterogeneous IoT platforms through the provided security interoperability support access control framework. The interoperability support unit 1120 may support interoperability based on an interoperability access token (IAT) issued based on OAuth 2.0 (i.e., ACMD, IMD, MROPC, MCC) extended from the IoT server platform. For example, the interoperability support unit 1120 may issue an interoperability access token (IAT) based on Multiple Clients' Credentials (MCC) through a security interoperability support access control framework. The interoperability support unit 1120 may request an interoperability access token (IAT) having the authority to access a plurality of IoT server platforms by using the requestor's credentials registered in the plurality of IoT server platforms from the requestor. The interoperability support unit 1120 verifies the credentials of the first IoT server platform among the credentials transmitted from the requester by the first IoT server platform, and among the credentials transmitted from the requester on the first IoT server platform. As a credential verification request is transmitted to the second IoT server platform, the second IoT server platform verifies the credential transmitted from the first IoT server platform and performs the credential verification to the first IoT server platform. The results of the dental verification can be delivered. The interoperability support unit 1120 may generate an interoperability access token (IAT) having a global access range accessible to the first IoT server platform and the second IoT server platform from the first IoT server platform. In this case, an area accessible to the resource may be limited according to the credential verification result in the first IoT server platform or the second IoT server platform. The interoperability support unit 1120 issues an interoperability access token (IAT) accessible to one or more of the first IoT server platform or the second IoT server platform to the requester from the first IoT server platform, and , The first IoT server platform or the second IoT server platform may be accessed based on an interoperable access token (IAT) issued from the first IoT server platform from the requestor.

As another example, the interoperability support unit 1120 is virtualized through A3 Framework as a Service (A3FaaS) and deployed on each IoT server platform through an access control framework supporting ACMD (Authorization Code for Multiple Domains). Interoperable access token (IAT) can be issued based on. The interoperability support unit 1120 obtains and obtains permission from resource owners in order to obtain the authority for the resource requesting access as resources for access from the client are specified and issuance of an interoperable access token (IAT) is requested. The obtained permission is transmitted to the A3 server, the authorization code is issued to the client through the verification result of verifying the permission transmitted from the client in the A3 server, and the authorization code issued from A3 is delivered to the A3 server by the client. After verifying the authorization code received from the client in the A3 server, an interoperable access token (IAT) can be issued to the client.

As another example, the interoperability support unit 1120 is an interoperable access token based on IMD (Implicit for Multiple Domains) through a secure interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform. (IAT) can be issued. The interoperability support unit 1120 provides the access range of the resource requested from the client and the redirection URI for issuing the interoperability access token (IAT), in order to obtain the authority for the access range of the requested resource through the login process. After obtaining the permission of the owners, passing the permission to the A3 server, and verifying the resource requested from the client in the A3 server, the interoperation policy of the domain where the requested resource is located, and the credential of the requested resource, interoperation with the client Can pass an access token (IAT).

As another example, the interoperability support unit 1120 is virtualized through A3FaaS and interoperable based on MROPC (Multiple Resource Owners' Password Credentials) through an access control framework that supports security interoperability deployed on each IoT server platform. Can issue an access token (IAT). The interoperability support unit 1120 receives the credentials of the resource owners previously stored from the client or the credentials of the resource owners to request the resource, transmits the access range of the requested resource and the resource owner's credentials to the A3 server, and A3 The server can issue an interoperable access token (IAT) by verifying the access range of the resource requested from the client and the resource owner's credentials.

As another example, the interoperability support unit 1120 is an interoperable access token based on MCC (Multiple Clients' Credentials) through a security interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform. (IAT) can be issued. The interoperability support unit 1120 delivers the credentials of the clients related to the access range of the resource from the client to the A3 server, verifies the client credentials transmitted from the A3 server, and updates the access range of the resource, and then the interoperability access token (IAT) can be issued.

The apparatus described above may be implemented as a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the devices and components described in the embodiments are, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA). , A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, such as one or more general purpose computers or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications executed on the operating system. In addition, the processing device may access, store, manipulate, process, and generate data in response to the execution of software. For the convenience of understanding, although it is sometimes described that one processing device is used, one of ordinary skill in the art, the processing device is a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of these, configuring the processing unit to behave as desired or processed independently or collectively. You can command the device. Software and/or data may be interpreted by a processing device or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. Can be embodyed in The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of the program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

As described above, although the embodiments have been described by the limited embodiments and drawings, various modifications and variations are possible from the above description by those of ordinary skill in the art. For example, the described techniques are performed in a different order from the described method, and/or components such as a system, structure, device, circuit, etc. described are combined or combined in a form different from the described method, or other components Alternatively, even if substituted or substituted by an equivalent, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and claims and equivalents fall within the scope of the claims to be described later.

Claims (18)

In the interoperability support access control method,
Providing a security interoperability support access control framework by virtualizing a layer for access control; And
Supporting interoperability between heterogeneous IoT server platforms through a security interoperability support access control framework based on the virtualized layer
Including,
The step of supporting the interoperability,
The IoT server platform supports interoperability based on an interoperable access token (IAT), and through the security interoperability support access control framework, ACMD (Authorization Code for Multiple Domains), IMD (Implicit for Multiple Domains), An interoperable access token (IAT) is issued based on MROPC (Multiple Resource Owners'Password Credentials) and MCC (Multiple Clients' Credentials), and the multiple Request an interoperable access token (IAT) having access to the IoT server platforms, and the first IoT server platform verifies the credentials of the first IoT server platform among the credentials transmitted from the requester. , As a credential verification request is transmitted from the first IoT server platform to a second IoT server platform among the credentials transmitted from the requester, the second IoT server platform is transmitted from the first IoT server platform. The credential is verified, and the credential verification result of performing the credential verification is transmitted to the first IoT server platform, and the first IoT server platform and the second IoT server platform are in the first IoT server platform An interoperable access token (IAT) having a global access range accessible to is generated, and the area accessible to the resource is restricted according to the result of credential verification in the first IoT server platform or the second IoT server platform. , The first IoT server platform issues an interoperable access token (IAT) accessible to any one or more IoT server platforms of the first IoT server platform or the second IoT server platform to the requester, and the issuance Passed the interoperable access token (IAT) to the requester and , Accessing the first IoT server platform or the second IoT server platform based on an interoperable access token (IAT) issued from the first IoT server platform from the requestor
Interoperability support access control method comprising a. The method of claim 1,
Providing the security interoperability support access control framework,
Providing a security interoperability support access control framework virtualized as one layer for access control of authentication, authorization, and auditing to the IoT server platform
Interoperability support access control method comprising a. delete delete delete delete delete delete delete The method of claim 1,
The step of supporting the interoperability,
Interoperable access token (IAT) based on ACMD (Authorization Code for Multiple Domains) through access control framework that supports security interoperability virtualized through A3FaaS (A3 Framework as a Service) and deployed on each IoT server platform. Steps to issue
Interoperability support access control method comprising a. The method of claim 10,
The step of supporting the interoperability,
As resources for access from the client are specified and the issuance of an interoperable access token (IAT) is requested, the resource owners' permission is obtained to obtain the permission for the resource requesting the access, and the obtained permission is transferred to the A3 server. And the A3 server issues an authorization code to the client through a verification result of verifying the authorizations transmitted from the client, and the client sends the authorization code issued from the A3 to the A3 server again, After verifying the authorization code received from the client in the A3 server, issuing an interoperation access token (IAT) to the client
Interoperability support access control method comprising a. The method of claim 1,
The step of supporting the interoperability,
Issuing an interoperable access token (IAT) based on IMD (Implicit for Multiple Domains) through a secure interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform.
Interoperability support access control method comprising a. The method of claim 12,
The step of supporting the interoperability,
As the access range of the resource requested from the client and the redirection URI to receive the interoperable access token (IAT) are delivered, the resource owners' permission is obtained to obtain the authority for the access range of the requested resource through the login process, Transmitting the permission to the A3 server, verifying the resource requested from the client in the A3 server, the interoperation policy of the domain in which the requested resource is located, and the credential of the requested resource, and then accessing the interoperation to the client. Passing the token (IAT)
Interoperability support access control method comprising a. The method of claim 1,
The step of supporting the interoperability,
Issuing an interoperable access token (IAT) based on MROPC (Multiple Resource Owners' Password Credentials) through an access control framework that supports security interoperability virtualized through A3FaaS and deployed in each IoT server platform.
Interoperability support access control method comprising a. The method of claim 14,
The step of supporting the interoperability,
Receives pre-stored resource owners' credentials from a client or resource owners' credentials for requesting a resource, transmits the requested resource access range and the resource owner's credentials to the A3 server, and the A3 server from the client Issuing an interoperable access token (IAT) by verifying the access range of the requested resource and the resource owner's credentials
Interoperability support access control method comprising a. The method of claim 1,
The step of supporting the interoperability,
Issuing an interoperable access token (IAT) based on MCC (Multiple Clients' Credentials) through a secure interoperability support access control framework virtualized through A3FaaS and deployed on each IoT server platform
Interoperability support access control method comprising a. The method of claim 1,
The step of supporting the interoperability,
The client delivers the credentials of the clients related to the access range of the resource to the A3 server, verifies the client credentials transmitted from the A3 server, updates the access range of the resource, and issues an interoperable access token (IAT). Steps to
Interoperability support access control method comprising a. In the control system for interoperability support access control,
A framework providing unit that provides a security interoperability support access control framework by virtualizing a layer for access control; And
Interoperability support unit that supports interoperability between heterogeneous IoT server platforms through an access control framework that supports security interoperability based on the virtualized layer.
Including,
The interoperability support unit,
The IoT server platform supports interoperability based on an interoperable access token (IAT), and through the security interoperability support access control framework, ACMD (Authorization Code for Multiple Domains), IMD (Implicit for Multiple Domains), An interoperable access token (IAT) is issued based on MROPC (Multiple Resource Owners'Password Credentials) and MCC (Multiple Clients' Credentials), and the multiple Request an interoperable access token (IAT) having access to the IoT server platforms, and the first IoT server platform verifies the credentials of the first IoT server platform among the credentials transmitted from the requester. , As a credential verification request is transmitted from the first IoT server platform to a second IoT server platform among the credentials transmitted from the requester, the second IoT server platform is transmitted from the first IoT server platform. The credential is verified, and the credential verification result of performing the credential verification is transmitted to the first IoT server platform, and the first IoT server platform and the second IoT server platform are in the first IoT server platform An interoperable access token (IAT) having a global access range accessible to is generated, and the area accessible to the resource is limited according to the result of credential verification in the first IoT server platform or the second IoT server platform. , The first IoT server platform issues an interoperable access token (IAT) accessible to any one or more IoT server platforms of the first IoT server platform or the second IoT server platform to the requester, and the issuance Passed the interoperable access token (IAT) to the requester and , Access to the first IoT server platform or the second IoT server platform based on an interoperable access token (IAT) issued from the first IoT server platform from the requestor.
Control system.

Images