RO138236A0 - Hybrid cloud security system - Google Patents

Abstract

The invention relates to a hybrid cloud security system. According to the invention, the system defines a list of owners, each having a list of communities, which have, in their turn, a list of users and a list of roles, as well as the user-role multiple correspondence, where the owners have associated a list of web applications they own, each having associated a client_id to be used by Oauth protocol and a public key from a pair of cryptographic keys, the private key being known exclusively by the owner of the application, where, based on said definitions, a process for authorizing the access to the web application, with a correspondence between the global identity and the local identity and the setting of environment variables which configure the application, a process for authorizing the programmatic access from one application to the other and a process for creating invitations for new users are defined.

Description

RO 138236 AO

Hybrid Cloud Security System Description

State of the art

STATE OFFICE FOR INVENTIONS AND TRADEMARKS

The integration of applications used by various organizations, developed in-house or standard software products implemented, is a major problem with a large weight in the cost of digital transformation of the organization. Managing the identity of users and authorizing their access is a basic problem, for which various solutions have been discovered. among them are the Oauth protocols, for delegating access authorization to an authorization server, and OpenID Connect for identity management over an Oauth protocol. These solutions describe the basic procedures for authorization, with the details being generic and left up to those who decide to use them.

Technical problem

The development of public cloud infrastructures has allowed application servers to be run on public servers. These servers can be private, belonging to a certain owner, but there can also be public applications owned by IT service providers with general applicability. in parallel there are the legacy applications, which run on servers in local networks and are not accessible from the Internet.

User identity management is handled in most software applications, internally or through integrations with other services. Changing the identity management method involves a major rewrite of the programs with which these applications are made, which may not even be possible if the sources are not available or the change is not permitted by the user license. Single sign on solutions, such as those developed on the basis of the OpenID Connect protocol, allow a unique identity but do not include solutions for the integration of pre-existing identity management systems.

Description of the invention

The invention consists of a group of interdependent processes for defining and organizing identities, applications and access rights, for verifying identity and authorizing access and ensuring data correspondence between applications, for creating users by invitation and for authorizing programmatic calls from one application to another.

The identity verification and access authorization process is shown in figure 1 and described below. It is based on a server that responds to the OpenID Connect protocol in a specific way correlated with the rest of the methods of the invention, which has available a series of interfaces specific to the present invention. This server can be a single Web server program running on a publicly accessible computer on the Internet, but it can also be a group of computers organized in a cluster running Web servers and an automatic load balancer in parallel, connected to a database.

Page 1 J 10

RO 138236 AO in the system there are one or more web servers running an application, hereinafter called planets. A planet can be a single program or also a cluster and a database server.

When the user wants to access an application on a planet (step 1 in Figure 1), an access control module configured to filter all HTTP requests to the planet triggers an Oauth authorization process with a code-grant authorization, redirecting the user to the OpenID server (step 2 in Figure 1), simultaneously creating a planet-wide session and setting an HTTP cookie in the redirect response.

The Openld server verifies the user's identity through the methods established when defining it in the system and through dialogue with the user (step 3 in figure 1). If the user's identity and presence are confirmed, the server issues an authorization code and opens a user session identified by a secure cryptographic code stored in an HTTP cookie set in the Oauth authorization code response (step 4 in Figure 1).

The user then accesses the planet by presenting this authorization code (step 5 in figure 1) to the access control module on the planet. It verifies the authenticity of the code by contacting the OpenID server (step 6 figure 1), where it in turn presents a JWT token signed with the planet's private key and obtains another JWT token with the data associated with the user, signed by the OpenID server and authenticated by the module access control using the public key of the OpenID server.

The access control module determines the local identity corresponding to the user identifier. If there is no local identity, it checks for a planet access invitation according to the user creation process described below, and if it finds one, it associates the local identity with the user identifier received from OpenID. If there is no invitation, it creates a new local identity based on the user data received from the OpenID server. The local identity may be pre-existing, from a legacy application. The application has full freedom to manage local identities, the access control module realizing the correspondence local identity - global identity.

After determining the local identity, the access control module verifies that there is a correspondence between the roles in the user data received from the OpenID server and the access rights in the web application, updating if necessary the access rights to match the globally assigned roles.

After determining the local identity, the access control module then sets in the existing application on the planet the user according to the already determined local identity and sets the environment variables with the values received from the OpenID server.

Page 2 | 10

RO 138236 AO

The process of defining and organizing applications, identities and access rights is based on a series of concepts and their relationships, shown in figure 2 and described below.

owners are defined in the system, who are the owners of identities and applications.

Each owner has an associated list of planets, which are web applications running on a public or private server, in the cloud or on your local network. A planet can represent a single Web server program running on a server, but it can also be a group of programs and servers that work together to serve Web pages. For example a cluster running an application server and a database server used by them. Each planet has associated:

• a URL that is the basis for ΗΤΓΡ requests through which that program produces web pages • a clientjd in the sense of the Oauth protocol • the public key from a pair of cryptographic keys

Each owner has a list of communities associated with it, identified by a unique alphanumeric code within the owner. Each community contains a list of users, identified both by a unique identifier at the OpenID server level and by a name (alphanumeric code) unique within the community. The unique identifier is not known to the user, but the name can be known and used by the user to identify himself.

At the owner, community or user level, it will be possible to specify the identification methods that the user can opt for as well as the authentication method with which the user certifies at the request of the OpenID server that he is present. Identification and authentication methods are not the subject of the present invention, being only necessary to exist. At a minimum, identification can be done through the user name and authentication through the presentation of a password. The OpenID server must provide the User Interface for identification and authentication.

The process of creating invitation-based user accounts begins on the planet by creating a local candidate identity and a local invite identifier. These are sent to the OpenID server in a JWT token signed with the planet's private key, which includes the code of the community the user is invited to and the web page to direct the user to after accepting the invitation. The OpenID server registers the invitation and returns an invitation URL that will be forwarded by the planet to the inviting user. It connects to this URL that points to a specific page on the OpenID server where the user will enter the data necessary to create a user in the specified community and opt for an authentication system and enter any necessary data (password, fingerprint, etc.). Once the data is entered, the OpenID server will redirect the user to an access point in the access control module, which will validate the invitation to not be

Page 3 | 10

RO 138236 AO reused and will associate the candidate local identity with the user, then redirect the user to the page specified when creating the invitation.

The process of authorizing programmatic calls from one web application to another web application consists of creating a JWT token that includes the clientjd of the source planet and optionally the clientjd of the destination planet, signed with the planet's private key, which will be included in the HTTP Authorization header of the call to the corresponding web application (destination planet) as a bearer token. On the destination planet the access control module will verify the bearer token using the public key of the source planet, obtained based on the source clientjd from the Openld server through the access point dedicated for this purpose. If there is also a destination clientjd in the bearer token it must be checked to match the destination planet.

Advantages of the invention

The group of procedures described allows the integration of existing Web applications, which may have a pre-existing identity management system. Applications can have different owners, who decide who can access them, and can specify these rules in the system for the system to apply automatically. application registration is done through a single pair of cryptographic keys, with a private key known exclusively to the application owner.

The procedures do not require the web application to be on a public server but can be a private server, which is not accessible from the Internet, allowing the realization of hybrid cloud applications, which integrate public web applications with private applications installed in local networks.

The processes are based on the widely adopted Oauth and OpenID Connect protocols and include specific options for these protocols that allow for simplifying system configuration and administration, integrating legacy applications that had their own identity management systems, and simultaneously securing direct programmatic calls between applications.

Example of realization

An embodiment of the described methods can be written in Java using J2EE application servers. For basic functionality including cryptography and JWT there are Java libraries available. Functions to access a database of owners, communities, users, roles, and planets can be written in Java on the OpenID server. Specific servlets can then be written for the call points specified in the OpenID protocol to respond according to the methods described in the invention, as well as the specific access points described in the invention for obtaining the public key of the OpenID server, the public key of a planet based on the clientjd, a URL for an invite.

Page 4 | 10

RO 138236 AO

An example JSON with the data obtained from the userinfo access point:

userJD: 1, clientJd: 16373833354, username: user, complete_name: Test User, email: test@crisoft.ro, phone: +40-744-555555, owner: CRISOFT, community: DEV env : { theme: crosweb_dark, language: RO roles: (management, sales] }

Bibliography

1. The OAuth 2.0 Authorization Framework - Internet Engineering Task Force - RFC 6749 - https://www.ietf.org/rfc/rfc6750.txt

2. OAuth 2.0 Authorization Server Metadata - Internet Engineering Task Force - RFC 8414 - https://www.ietf.org/rfc/rfc8414.txt

3. OpenID Connect Core 1.0 - OpenID Foundation - https://openid.net/specs/openidconnect-core-1 O.html

4. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - Internet Engineering Task Force - RFC 7523 https://www.ietf.org/rfc/rfc7523.txt

5. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 - Internet Engineering Task Force - RFC 3447 https://www.ietf.org/rfc/rfc3447.txt

6. JSON Web Token (JWT) - Internet Engineering Task Force - RFC 7519 - https://www.ietf.org/rfc/rfc7519.txt

Page 5 | 10

Claims (10)

RO 138236 AO demand 1. Procedure for defining an identity management system characterized in that it ensures the definition of a list of owners, each having an associated list of communities, each community comprising a list of users, a list of roles and a multiple correspondence between users and roles , simultaneously associating with each owner a list of servers running Web applications. 2. Particular to claim 1, the identification of the owner is done by a unique alphanumeric code, the identification of the community is done by a unique alphanumeric code within the owner, the identification of the user is done by a unique and simultaneous identifier and a unique name within community, and roles are identified by a unique alphanumeric code within the community. 3. Particular to claim 1, associating with each planet the clientjd in the sense of the Oauth protocol, the root URL of the web application running on that planet, and the public key from a cryptographic key pair where the private key is known only to the application running on the planet . 4. Particular to claim 1, the association with each user of a unique identifier, the community of which he is a part and its owner and a set of environmental variables in the form of code-value pairs. 5. Particular to claim 1, associating with each planet a list of access rights at owner, community, role or user level. 6. Method for the operation of a server for the OpenID Connect protocol characterized by the use of an identity management system according to the method of claim 1, which performs the authentication of client applications using clientjd and the public key defined according to the method of claim 2, extended with a point of programmatic HTTP access through which a planet's data can be obtained, namely clientjd, uri and public key. 7. Particular to claim 5, transmitting to a web application through the userinfo call within the OpenID Connect protocol the data associated with the user according to the method described in claim 1, including the list of roles associated with the user and the list of environment variables and their values. 8. Method for authorizing access to a web application characterized by the use of an access control module that filters all HTTP calls to a web application and authorizes access according to the OpenID Connect and Oauth protocols, configured specifically for the methods from claims 1 and dependent claims and claim 5 dependent ones, with authentication through a JWT token signed with the planet's private key and authentication of values received from the Openld server using the OpenID server's public key. 9. Particular to claim 8, the determination of the local identity specific to the Web application is made by the access control module based on a correspondence table between the user identifier and the local identity defined in the application, with the automatic creation of the local identity based on the information received from the server OpenID and any existing invitation in the access control module. P a g i n a 6 | 10 RO 138236 AO 10. Particular to claim 8, authorizing the programmatic call based on a JWT token to the bearer, signed using the private key of the source application and authenticating with the public key of the source application obtained from the OpenID server, signed with its private key. Page 7 | 10