Patent Description:
For example, identity management can involve various service functions, such as providing personalized, role-based, online, on-demand, content, and/or presence-based services to users and their devices. Identity management can also involve identity federation, such as relying on federated identity to authenticate a user without knowing his or her password. A federated identity in information technology is the means of linking a person's various digital identities and attributes, which may be stored across multiple distinct identity providers.

In a federated identity management, various policies, practices, and protocols may be implemented for exchanging authentication and authorization data between parties. For example, Security Assertion Markup Language (SAML) is an XML-based markup language for security assertions that service providers may use to make access-control decisions. As another example, OpenID Connect (OIDC) is another protocol that allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server. An application can choose to implement any identity authentication protocols that best fits the purpose of the application. Once the identity authentication protocol is determined, the policies are then defined and entered into the identity management service based on the format and requirements of the identity authentication protocol.

<CIT> describes a method and apparatus for integrating various network access control frameworks under the control of a single policy decision point (PDP). The apparatus supports pluggable protocol terminators to interface to any number of access protocols or backend support services. The apparatus contains Trust and Identity Mediators to mediate between the protocol terminators and a canonical policy subsystem, translating attributes between framework representations, and a canonical representation using extensible data-driven dictionaries.

<CIT> also constitutes relevant prior art which has been cited in the European Search report and used for the examination of the patent application corresponding to this present patent specification.

<CIT> describes a unified authorization system for an enterprise that includes heterogeneous access control environments. For example, components in the enterprise utilizing either JPS or OAM can both use the unified authorization system to perform authorization. A common policy store can contain policies applicable to diverse components in a canonical form conducive to varieties of access control models. The data model used within the common policy store can support access control features found in both JSP and OAM environments, such as both role-based policies and delegable access control administration. The common policy store can enable the querying and retrieval of authorization policies that are based on various access control models. A single unified administrator interface permits administrators of applications following any kind of access control model to administer policies for resources. A single unified policy decision engine can evaluate whether authorization policies are satisfied, regardless of the access control models that those policies follow.

<CIT> describes methods, systems, and computer program products that are provided for cross domain security information conversion. Embodiments include receiving from a system entity, in a security service, security information in a native format of a first security domain regarding a system entity having an identity in at least one security domain; translating the security information to a canonical format for security information; transforming the security information in the canonical format using a predefined mapping from the first security domain to a second security domain; translating the transformed security information in the canonical format to a native format of the second security domain; and returning to the system entity the security information in the native format of the second security domain.

This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description.

The embodiments described herein are related to protocol-agnostic configuring an identity claim policy that is to be applied to an application, such as a relying party application according to one of multiple identity authentication protocols. First, one or more identity claim policies are generated. One of the one or more identity claim policies is then applied to one or more applications. A claim policy includes one or more rule definitions for generating claims. Each of the one or more applications implements a particular identity authentication protocol that is one of the multiple identity authentication protocols.

In particular, for each of the one or more applications, the identity authentication protocol that is used by the corresponding application is determined. Based on the determined identity authentication protocol, one or more identity claims of the corresponding application is construed to correspond to the at least one identity claim policy.

In some embodiments, a user interface is displayed, and a user may be allowed to input, at the user interface, each of the one or more identity claim policies regardless of which identity authentication protocol is (or is to be) implemented at any particular application. A user may be allowed to input at the user interface to copy an existing identity claim policy. When the existing identity claim policy is copied, a new identity claim policy that is identical to the existing identity claim policy is generated. A user may also be allowed to modify an existing identity claim policy. Once the one or more identity claim policies are entered, a user may then be allowed to select one or more identity claim policies and one or more applications at the user interface and apply the selected one or more identity claim policies to the selected one or more applications.

For example, a user may copy an existing identity claim policy, and then modify the copied existing identity claim policy to create a new distinct identity claim policy. The user can then apply the new distinct identity claim policy to any number of applications regardless of which identity authentication protocol is (or is to be) implemented at each of these applications.

In some embodiments, after applying an identity claim policy to any application, the identity claim policy may be tested via a testing application. First, a test application may be launched. For each of the multiple protocols, a test request for accessing the test application may be generated. In response to the test request, a security token of the corresponding protocol may be received. The security token includes one or more identity claims. Once the security token is received, the one or more identity claims contained in the security token are decoded. The decoded one or more identity claims may then be displayed to a user.

Existing identity providers often require users to generate a separate identity claim policy for each application. As such, an application service provider is often required to create and maintain a claim policy for each application, which is cumbersome if the same claim policy needs to be applied to a different application.

Additionally, existing identity providers often require users to use different user interface for different authentication protocols. For example, if an application implements SAML protocol, a user is often required to use a SAML specific portal to define or update the set of identity claim policy for the particular application; if an application implements OIDC protocol, a user is often required to use an OIDC specific user interface (e.g., a command-line shell) to define or update the identity policy for the particular application. It is burdensome for users to familiarize with various user interfaces, claim formats, and commands for generating identity claims for different applications.

The principles described herein improve the functions of identity management systems by removing the requirement of the users to have to learn and use different user interfaces and/or portals to set up identity claim policies for each application depending on the protocols implemented in the application. Instead, the users are allowed to simply define a set of identity claim policies, and apply the set of identity claims to any number of applications, regardless of the protocol implemented in each application.

The embodiments described herein are related to protocol-agnostic configuring an identity claim policy that is to be applied to an application, such as a relying party application according to one of multiple identity authentication protocols. First, one or more identity claim policies are generated. At least one of the one or more identity claim policies is then applied to one or more applications. Each of the one or more applications implements a particular identity authentication protocol that is one of the multiple identity authentication protocols.

A claim policy may include one or more rule definitions for generating claims. For example, a rule definition may define a claim type by mapping a user attribute or a group attribute to the claim type. The mapped pair of the user attribute and claim type may become a part of the claim policy, such that the outgoing security token would include a claim that asserts the user attribute in the defined claim type.

Further, in some embodiments, the applying the at least one identity claim policy may include performing one or more transformations on the included at least one user attribute or group attribute or any constant value contained in the defined identity claim policy. The one or more transformations may include, but are not limited to: (<NUM>) an extraction transformation, (<NUM>) a regular text replacement transformation, (<NUM>) a to-upper-case transformation, and (<NUM>) a to-lower-case transformation.

Existing identity providers often require users to generate a separate identity claim policy for each application. As such, an application service provider is often required to create and maintain a claim policy for each application.

Additionally, existing identity providers often require users to use different user interfaces for different authentication protocols. For example, if an application implements SAML protocol, a user is often required to use a SAML specific portal to define or update the set of identity claim policy for the particular application; if an application implements OIDC protocol, a user is often required to use an OIDC specific user interface (e.g., a command-line shell) to define or update the identity policy for the particular application. It is burdensome for users to familiarize with various user interfaces, claim formats, and commands for generating identity claims for different applications.

The principles described herein improve the functions of identity management service systems by removing the requirement of the users to have to learn and use different user interfaces and/or portals to set up identity claim policies for each application depending on the protocols implemented in the application. Instead, the users are allowed to simply define a set of identity claim policies, and apply the set of identity claims to any number of applications, regardless of the protocol implemented in each application.

<FIG> illustrates an example environment <NUM> that includes a service provider <NUM>, an identity provider <NUM>, and a client <NUM>. The client <NUM> may be a web browser, a desktop application, and/or a mobile application. The service provider <NUM> may be providing multiple applications or services <NUM> to the customers. The ellipsis <NUM> represents that there may be any number of applications or services provided by the same service provider <NUM>. When a customer <NUM> accesses an application <NUM> provided by the service provider <NUM> via the client <NUM>, the customer <NUM> is often required to enter his/her credentials. A common credential includes a username and password. The username specifies who the customer is, and the password proves the customer is who he/she says he/she is. After it is proved that the username and the password match, the service provider <NUM> can then give the customer access to the service.

It may appear to the customer <NUM> that the service provider <NUM> determines whether the username and the password match. However, in a modern secure web service environment <NUM>, the customer's username and password are often managed by an identity provider <NUM>. Just like when you show your photo ID (e.g., driver's license) to another person, the other person believes you, because the driver's license is issued by a government entity, who has information about you and has verified such information to be true. In that sense, the identity provider <NUM> acts as an online federation that governs and manages the identities of many users. As such, common standards and protocols to manage and map user identities between identity providers across organizations (and security domains) are sometimes called "federation.

As illustrated in <FIG>, when the customer <NUM> requests for accessing the service provided by the service provider <NUM>, the service provider <NUM> may require the customer <NUM> to prove his/her identity via the identity provider <NUM>. For example, the customer <NUM> may be redirected to a customer login interface provided by the identity provider <NUM>. The customer <NUM> can then enter his/her username and password at the interface. The identity provider <NUM> receives the username and password entered by the customer <NUM> and determines whether the username and password match. If the username and password match, the identity provider <NUM> then causes a response or a security token to be generated. The response or the security token often includes one or more identity claims that are related to the user, which has been authenticated by the identity provider <NUM>.

An identity claim is a piece of identity information about a user, such as name, email address, age, membership in a particular role (e.g., executive). The more claims the service provider <NUM> receives, the more the service provider <NUM> will know about the user. As such, the service provider <NUM> does not need to look up the user's attributes in a directory. Instead, the identity provider <NUM> generates the claims, and the service provider <NUM> examines them. Each claim has an issuer. The service provider <NUM> trusts the claim only as much as it trusts the issuer. For example, the service provider <NUM> would probably trust a claim made by an employer's domain controller more than it trusts a claim made by the user himself/herself. The identity provider <NUM> presents claims with a claim type, which has an issuer property that allows the service provider to find out who issued the claim. The claims are then wrapped into a security token, which encrypts, encode, and/or signs the claims.

When the service provider <NUM> builds an application that relies on claims, the service provider <NUM> is building a relying party application <NUM>, which is also called a "claim-aware application" or "claims-based application" (hereinafter also referred to as "application" or "service"). A relying party application consumes the security tokens and extracts the claims from the security tokens to use them for identity-related tasks. In order to make all of this interoperable, the relying party application <NUM> needs to choose an identity authentication protocol and configure a claim policy that is to be implemented with the identity provider <NUM>. The authentication protocol determines how to request and receive security tokens, and the claim policy determines what type of claims and/or identity information is required by the relying party application. For example, the relying party application <NUM> may require a user's email address, principal name (UPN), and/or last name to be included in the identity claims.

Based on the protocol and the claim policy specified by the application <NUM>, after the identity provider <NUM> authenticates the user, the identity provider issues a claim that complies with the application's claim policy. Depending on the implemented protocol, the identity provider <NUM> may send a response or token containing the claim to the client <NUM>, and the client <NUM> then presents the response or token to the relying party application <NUM>. Alternatively, or in addition, the identity provider <NUM> may require the customer <NUM> to expressly grant permission for the service provider <NUM> to have access to certain user information before sending the response or token to the client <NUM> or directly to the service provider <NUM>.

Different authentication processes and token formats are implemented in different identity authentication protocols. Depending on the use case, a service provider may determine which protocol is to be implemented in each application. For example, Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are two commonly implemented protocols.

Since SAML and OICD are commonly implemented in applications, we will provide a brief introduction to these two protocols with respect to <FIG>. <FIG> is a diagram that illustrates example communication flows that may occur amongst a client <NUM>, an identity provider <NUM>, and a relying party application <NUM> when the SAML protocol is implemented at the relying party application <NUM>. The client <NUM>, the service provider <NUM>, the relying party application <NUM>, and the identity provider <NUM> may correspond to the respective client <NUM>, service provider <NUM>, relying party application <NUM>, and identity provider <NUM> of <FIG>.

When a customer <NUM> requests for access resource from the relying party application <NUM> via the client <NUM> (represented by arrow <NUM>), the relying party application <NUM> generates a SAML authentication request, and redirect the client <NUM> to the identity provider <NUM> (represented by arrow <NUM>). The client <NUM> then redirects the authentication request to the identity provider <NUM> (represented by arrow <NUM>). In response to the authentication request, the identity provider <NUM> displays a login page at the client <NUM> (represented by arrow <NUM>). The customer <NUM> can then enter his/her username and password at the displayed login page (represented by arrow <NUM>). The identity provider <NUM> verifies the user-entered username and password first, then issues a response or token (represented by arrow <NUM>). The client <NUM> receives the response or token from the identity provider <NUM>, and then passes on the response or token to the relying party application <NUM> (represented by arrow <NUM>). Once the relying party application <NUM> receives the security token, the relying party application <NUM> decodes the security token to obtain the identity claims contained therein, and then grants the client <NUM> access to the requested resource (represented by arrow <NUM>).

Under the SAML protocol, the response/token is required to be written in XML format. The authenticated identity claims embedded in the SAML response are also written in XML format. <FIG> illustrates an example set of identity claims 200B that may be embedded in a security token under the SAML protocol. As illustrated in <FIG>, the identity claims may be asserted in an attribute statement. The attribute statement may have one or more attribute elements, including "userid", "mail", and "EmployeeID". The "userid" attribute may indicate the user ID of the subject user. For example, the user ID of the authenticated user may be "abcd". The "mail" attribute may indicate the email address of the user. For example, the email address of the user may be mail@example. The "EmployeeID" may indicate the user's employment affiliation and role at the employer's organization. For example, the user's employer may be "employer X", and his/her role at the employer's organization may be "role Y".

In addition to the SAML protocol, the OIDC protocol is another commonly implemented protocol. <FIG> is a diagram that illustrates example communication flows that may occur amongst a client <NUM>, an identity provider <NUM>, and a relying party application <NUM> when the OIDC protocol is implemented. The client <NUM>, the service provider <NUM>, the relying party application <NUM>, and the identity provider <NUM> may correspond to the respective client <NUM>, service provider <NUM>, relying party application <NUM>, and identity provider <NUM> of <FIG>.

As illustrated in <FIG>, when the client <NUM> requests for accessing a resource from the relying party application <NUM> (represented by arrow <NUM>), the relying party application <NUM> generates an OIDC authentication request and instructs the client <NUM> to redirect authentication request to the identity provider <NUM> (represented by arrow <NUM>). The OIDC authentication request includes one or more parameters or attributes related to the user that the service provider would like to obtain. The client <NUM> then redirects the authentication requests to the identity provider <NUM> (represented by arrow <NUM>). In response to receiving the authentication request, the identity provider <NUM> displays a login page at the client <NUM> (represented by arrow <NUM>). The customer <NUM> then enters his/her credentials (e.g., username and password) at the login page (arrow <NUM>).

After the identity provider <NUM> receives and verifies the customer's credentials, the identity provider <NUM> then requests the user to consent to allow the relying party application <NUM> to access the requested parameters or attributes (represented by arrow <NUM>). If the customer <NUM> provides the consent (represented by arrow <NUM>), the identity provider <NUM> then sends the client <NUM> an authorization code and redirect the client <NUM> back to the relying party application <NUM> (represented by arrow <NUM>).

The client <NUM> then passes on the authorization code to the relying party application <NUM> (represented by arrow <NUM>). The relying party application <NUM> then presents the authorization code to the identity provider <NUM> to obtain ID token, access token and/or refresh token (arrow <NUM>). The relying party application <NUM> can then decode the ID token and/or access token to obtain the parameters or attributes of the user (i.e., the claims). After the relying party application <NUM> obtains the parameters or attributes of the user, the relying party application <NUM> may grant the client <NUM> the access to the requested resource (arrow <NUM>).

Under the OIDC protocol, the ID token is written in JSON web token (JWT) format. The JSON web token is then encoded into ASCII strings. For example, base64url may be used to encode a JSON web token. <FIG> illustrates an example encoded OIDC ID token 300B, and <FIG> illustrates an example decoded OICD ID token 300C. As illustrated in <FIG>, the encoded OICD ID token is a long ASCII string, that is hardly understandable by any human. The decoded OICD ID token is in JSON format, which includes various attributes and parameters that are related to the user. For example, as illustrated in <FIG>, the ID token includes the claim issuer, the user's name, gender, date of birth, email, and a URL to the user's picture. Based on the ID Token, the relying party application <NUM> knows that the claim issuer is http://server. com, that the user's name is Jane Doe, that she is a female, that she is born on October <NUM>, <NUM>, that her email is janedoe@example. com, and that her picture can be accessed at http://example. com/janedoe/me.

As briefly discussed above, no matter what protocol the service provider <NUM> chooses to implement in each relying party application <NUM>, the service provider <NUM> also needs to configure the claim policy for each application <NUM>. Claim policies define how claims are construed, and what information is required to be authenticated. For example, the relying party application <NUM> may require the claims to include an authenticated email address.

Existing identity providers often require a user to manually configure a claim policy for each application. <FIG> illustrates such an example environment <NUM>, in which various identity claim policies are being configured for various applications. As illustrated in <FIG>, different user interfaces may be available for applications that implement different identity authentication protocols. For example, a web portal <NUM> may be used for configuring claim policies for applications <NUM>, <NUM> that implement protocol A. PowerShell <NUM> may be used for configuring claim policies for applications <NUM>, <NUM> that implement protocol B. The ellipsis <NUM> and <NUM> represent that there may be any number of additional identity authentication protocols that may be implemented by various applications.

As illustrated in <FIG>, in the existing environment <NUM>, a service provider providing applications and services to users may be required to configure claim policies for each of its applications separately. For example, for protocol A application <NUM>, the service provider may be required to manually set up the particular claim policy <NUM>; for protocol B application <NUM>, the service provider may also be required to manually set up the particular claim policy <NUM>. The ellipsis <NUM> represents that there may be any number of applications that implement protocol A, and each of these applications needs to have its particular claim policy set up manually via the web portal <NUM>. Similarly, for protocol B application <NUM>, the service provider may be required to manually set up the particular claim policy <NUM>; for protocol B application <NUM>, the service provider may also be required to manually set up the particular claim policy <NUM>. The ellipsis <NUM> represents that there may be any number of applications that implement protocol B, and each of these applications needs to have its particular claim policy set up manually via PowerShell <NUM>.

As such, in the existing environment <NUM>, the users (e.g., programmers or IT professionals) at the service provider are required to be familiar with both the web portal <NUM> and the commands of Powershell <NUM> to be able to configure and/or modify the claim policies. Such a requirement is not only burdensome but also error-prone. The principles described herein improve the identity provider or identity management system by reducing the skill level and time required by the users at the service provider to set up the claim policies for applications. In particular, the principles described herein provide a single user interface that is protocol agnostic. The service provider can input the claim policies from the single user interface without having to know which particular identity authentication protocol is to be or has been implemented in any particular application. Further, each claim policy can be copied or modified, and be applied to multiple applications.

<FIG> illustrates an example environment <NUM>, which implements the single protocol-agnostic user interface <NUM> that allows service providers to define claim policies regardless of the identity authentication protocol implemented in any particular application. For example, the service provider may define claim policy <NUM> and claim policy <NUM>. The ellipsis <NUM> represents that there may be any number of claim policies that are defined by the same service provider. The service provider may then apply the claim policy <NUM> to protocol A application <NUM>, protocol B application <NUM>, and protocol B application <NUM>. Similarly, the service provider may apply the claim policy <NUM> to protocol A application <NUM>, and application <NUM>. The ellipsis <NUM> represents that there may be any number of applications that implement any identity authentication protocols, and any defined claim policy <NUM> may be applied to any one of these applications.

The user at the service provider does not need to specify or know about which identity authentication policy is actually implemented at each of the applications <NUM>-<NUM>. The identity provider identifies the protocol of each of the applications <NUM>-<NUM>, and based on the determined protocol, the identity provider implements the claim policies to the corresponding applications based on the corresponding protocol.

<FIG> illustrates an example user interface <NUM> that allows a user of the service provider to define or configure claim policies without knowing the identity authentication protocol implemented at any application. The user of the service provider may be a computer programmer or any IT professional that is tasked to configure the claim policies for one or more applications provided by the service provider. A claim policy may include one or more rule definitions for generating claims. For example, a rule definition may define a claim type by mapping a user attribute or a group attribute to the claim type. The mapped pair of the user attribute and claim type may become a part of the claim policy, such that the outgoing security token would include a claim that asserts the user attribute in the defined claim type. For example, the user interface <NUM> may include a claim rule name field <NUM> that allows the user to name each new claim rule. The user interface <NUM> may also includes an attribute directory or store field <NUM> that allows the user of the service provider to select or type in directories or databases that an organization uses to store its user accounts and their associated attribute values. For example, Active Directory may be selected. Active Directory is a directory owned by Microsoft that includes all users that log into a computer that is part of a windows domain.

The user interface <NUM> may also include a mapping table <NUM> that allows the service provider to select or type in one or more user attributes and respective outgoing claim types. For example, the service provider can select attribute "E-Mail-Addresses" <NUM> to be included in claim type "E-Mail Address" <NUM>, the service provider can also select attribute "User-Principal-Name"<NUM> to be included in claim type "UPN" <NUM>, and service provider can also select attribute "Display-Name" <NUM> to be included in claim type "Name" <NUM>.

Further, some claim definitions may further include one or more conditions <NUM>, <NUM>, <NUM>. For example, as illustrated in <FIG>, the "E-Mail Address" <NUM> claim type may include condition A <NUM> and condition B <NUM>. When one or more conditions are included in a claim definition, only when the conditions are satisfied, a claim may be emitted in a security token. For example, a condition (e.g., condition A <NUM>) may require only claim values that match a specific e-mail suffix value. When such a condition is required, only if the incoming claim type equals the specified claim type, and its value begins with the specified claim value, the claim will be emitted in a token. As another, a condition (e.g., condition B <NUM>) may require a specific claim value. When such a condition is required, only if the incoming claim type equals the specified claim type, and its value equals the specified claim value, then the claim will be emitted in a token. As yet another example, a condition (e.g., condition C <NUM>) may be passing through only claim values that start with a specific value. If incoming claim type equals the specified claim type, and its value begins with the specified claim value, the claim will be emitted in a token. When there is no additional condition, all claim values will be emitted in a token, as long as the claim type equals the specified claim type.

The ellipses <NUM>, <NUM>, <NUM> represent that additional claim rule definitions may be entered to be part of the claim policy. The user interface <NUM> is merely an example. Additional user input fields may be included in the user interface <NUM>. For example, the service provider may also be allowed to enter one or more group attributes and respective outgoing claim types. Further, different layouts and graphic features may also be implemented in the user interface <NUM>. For example, the conditions <NUM>, <NUM>, <NUM> may not be organized in the same table as the attribute and claim type. The conditions may be defined as a separate category or through a separate user interface, and a user can select various conditions to be applied to various claim types.

After one or more claim policies are defined, the service provider may be allowed then apply the defined claim policies to one or more applications. <FIG> illustrates an example user interface <NUM> that displays a claim policy list <NUM> and an application list <NUM>. The claim policy list <NUM> includes claim policy A <NUM> and claim policy <NUM>, each of which may be previously configured via user interface <NUM> of <FIG>. The ellipsis <NUM> represents that there may be any number of claim policies defined and listed on the claim policy list <NUM>. The application list <NUM> includes application A <NUM> and application B <NUM>. The ellipsis <NUM> represents that there may be any number of applications listed on the application list <NUM>.

The user at the service provider can simply select a claim policy in claim policy list <NUM>, and any number of applications in the application list <NUM> to apply the selected claim policy to the selected applications. For example, the service provider may select claim policy A <NUM> and application A and application B, then click "apply" button <NUM> to apply the claim policy A to both application A <NUM> and application B <NUM> regardless of what protocol each of applications A and B <NUM>, <NUM> implements. Similarly, the user can also clear the applied claim policy by clicking the "clear" button <NUM>. Further, a user can also select to copy an existing claim policy to create a new claim policy using the "copy" button <NUM>, or modify an existing claim policy using the "modify" button <NUM>.

In some embodiments, the applying the at least one identity claim policy may include performing one or more transformations on the included at least one user attribute or group attribute or any constant value contained in the defined identity claim policy. The one or more transformations may include, but are not limited to: (<NUM>) an extraction transformation, (<NUM>) a regular text replacement transformation, (<NUM>) a to-upper-case transformation, and (<NUM>) a to-lower-case transformation.

An extraction transformation is generally directed to a procedure of copying data from one or more sources into a destination system which represents the data differently from the one or more sources. For example, the same data written in XML format may be extracted and transformed into JSON format, and vice versa. A RegexReplace transformation is a transformation that replaces part of a text string with a different text string. For example, the standard claim types may be named slightly differently under different identity authentication protocols. The system may use the RegexReplace transformation to transform the claim type names to be consistent with the claim type names that comply with different identification authentication protocols. Similarly, different identification authentication protocols may also have different case sensitive spelling requirements. The system may also be able to perform to-upper-case transformation, and to-lower-case transformation to transform the attribute and claim type defined in the claim policy, such that the transformed attribute and claim type would comply to the requirement of each particular identity authentication protocol.

As such, the users at the service provider do not need to have the knowledge of which identity authentication protocol is implemented at each application to define and apply the claim policies to each application. The identity provider determines which identity authentication protocol is implemented in each application, and based on the determination, the identity provider applies the claim policies to the application. <FIG> merely illustrates a simple example user interface <NUM>. The additional or different user interface elements or different layout may be implemented to achieve the same or additional functions.

Further, to make sure the generated claim policies will work as intended, the principles described herein also provide a testing mechanism that allows the users at the service provider to test the newly defined claim policies using a test application. <FIG> illustrates a flowchart <NUM> of an example testing mechanism. The testing mechanism may be performed at any one of the applications after a claim policy is applied to the application. The test mechanism generates test requests, traverses each of the multiple identity authentication protocols to generate a corresponding security token, and eventually decode each security token and displays the decoded claims to the user, such that the user can visually see whether the decoded claims are what the user has intended to receive, and whether the claim policy is properly construed.

As illustrated in <FIG>, when a user initiates a testing process, the system setups a test framework (<NUM>). When a test is initiated (act <NUM>), it is determined whether a testing application URL is to be added to the reply URL, which specifies where the test application expects to receive the responses and/or tokens (<NUM>). If the determination is no, the test stops (<NUM>). If the determination is yes, the reply URL is added with the test application URL (<NUM>), and the test application is launched (<NUM>). Once the test application is launched, each of the multiple identity authentication policies is traversed one at a time.

For example, as illustrated in <FIG>, it is first determined whether a SAML token is to be tested (<NUM>). If the determination is yes, a SAML request is sent to the test application (<NUM>). Once the test application receives the SAML request, it sends a SAML response (i.e., token) back. After the test application receives the SAML response (<NUM>), the claim embedded in the SAML response is decoded and displayed to the user who has initiated the test (<NUM>).

On the other hand, if it is determined that SAML token is not to be tested, it is then determined whether OIDC ID token is to be tested (<NUM>). If it is determined that OIDC ID token is to be tested, an OIDC authorization request is sent to the test application (<NUM>). In response to the authentication request, the test application then receives an OICD ID token, which is often in JSON Web ID token (JWT) format (<NUM>). Next, it is then determined whether OICD ID access token is to be tested. If the determination is yes, a request is then sent with the client secret and resource ID (<NUM>). Once the client secret and resource ID are authenticated by the identity provider, a JWT access token for the resource may be generated and sent to the test application (<NUM>). After the JWT access token for the resource is received (<NUM>), the claims contained in the security token is then decoded and displayed to the user who has initiated the test (<NUM>). There may be additional identity authentication protocols (not shown) that may be implemented and tested.

Once the claim policy is tested under each of the multiple identity authentication protocols, the test URL may be removed, and the test may be terminated. As illustrated in <FIG>, after the claims contained in the SAML response or OIDC ID token are decoded and displayed, it is then determined whether the test application URL is to be removed (<NUM>). If it is determined that the test application URL is to be removed, the test application URL is removed (<NUM>), and the testing stops (<NUM>). After the claims are successfully decoded and displayed to the user, the test framework may be uninstalled or removed (<NUM>).

Although the method acts may be disused in a certain order or illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed.

<FIG> illustrates a flowchart of an example method <NUM> for protocol-agnostic configuring one or more identity claim policies. The method <NUM> includes generating one or more identity claim policies (act <NUM>) and applying at least one of the generated identity claim policies to one or more applications (act <NUM>). The act of generating the one or more identity claim policies (act <NUM>) may further include displaying a user interface (act <NUM>), and receiving a user input defining each of the one or more identity claim policies (act <NUM>). For example, the user interface may correspond to the example user interface <NUM> of <FIG>. The service provider may be allowed to enter a new claim policy by inputting one or more attributes and respective claim types (act <NUM>). The service provider may also be allowed copy an existing identity claim policy to generate a new policy (act <NUM>) and/or modify an existing identity claim policy (act <NUM>).

The act of applying at least one identity claim policy to one or more applications may include determining the identity authentication protocol that is implemented by the corresponding application (act <NUM>). In some embodiments, the applying the at least one identity claim policy may include performing one or more transformations on the included at least one user attribute or group attribute or any constant value contained in the defined identity claim policy (act <NUM>). The one or more transformations may include, but are not limited to: (<NUM>) an extraction transformation, (<NUM>) a regular text replacement transformation, (<NUM>) a to-upper-case transformation, and (<NUM>) a to-lower-case transformation. Based on the determined identity authentication protocol, construing one or more identity claims of the corresponding application that corresponds to the at least one identity claim policy (act <NUM>). For example, if it is determined that the identity authentication protocol is the SAML protocol, the identity claims will be construed to be in XML format; and if it is determined that the identity authentication protocol is the OIDC protocol, the identity claims will be construed to be in JWT format.

Further, the method <NUM> may also include testing at least one of the identity claim policies (act <NUM>). The act of testing the at least one identity claim policy (act <NUM>) includes launching a test application (act <NUM>) and testing each one of the plurality of the protocols using the test application (act <NUM>). In particular, for each protocol, a test request is generated (act <NUM>). In response to the request, the identity provider generates a security token of the corresponding protocol. Once the test application receives the security token (act <NUM>), the test application decodes the claim(s) contained in the security token (act <NUM>) and displays the decoded claim(s) to the user (act <NUM>).

Finally, because the principles described herein may be performed in the context of a computing system. For example, each of the client <NUM>, identity provider <NUM>, service provider <NUM>, and relying party application <NUM> may be implemented at a computing system, some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> typically includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> may include a general-purpose processor and may also include a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other specialized circuit. The memory <NUM> may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.

In such a case, one of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer-readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

The term "executable component" is also well understood by one of ordinary skill as including structures, such as hardcoded or hard-wired logic gates, that are implemented exclusively or near-exclusively in hardware, such as within a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other specialized circuit.

For example, such computer-executable instructions may be embodied in one or more computer-readable media that form a computer program product. If such acts are implemented exclusively or near-exclusively in hardware, such as within an FPGA or an ASIC, the computer-executable instructions may be hardcoded or hard-wired logic gates.

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 1012A as well as input mechanisms 1012B. The principles described herein are not limited to the precise output mechanisms 1012A or input mechanisms 1012B as such will depend on the nature of the device. However, output mechanisms 1012A might include, for instance, speakers, displays, tactile output, holograms and so forth. Examples of input mechanisms 1012B might include, for instance, microphones, touchscreens, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Embodiments described herein may comprise or utilize a special purpose or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general-purpose or special purpose computing system.

Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other physical and tangible storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general-purpose or special purpose computing system.

Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general-purpose or special-purpose computing system.

Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions. Alternatively or in addition, the computer-executable instructions may configure the computing system to perform a certain function or group of functions.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, data centers, wearables (such as glasses) and the like.

The remaining figures may discuss various computing system which may correspond to the computing system <NUM> previously described. The computing systems of the remaining figures include various components or functional blocks that may implement the various embodiments disclosed herein as will be explained. The various components or functional blocks may be implemented on a local computing system or may be implemented on a distributed computing system that includes elements resident in the cloud or that implement aspect of cloud computing. The various components or functional blocks may be implemented as software, hardware, or a combination of software and hardware. The computing systems of the remaining figures may include more or less than the components illustrated in the figures and some of the components may be combined as circumstances warrant. Although not necessarily illustrated, the various components of the computing systems may access and/or utilize a processor and memory, such as processor <NUM> and memory <NUM>, as needed to perform their various functions.

As discussed above, each of the identity provider <NUM>, the client <NUM>, the service provider <NUM>, and the relying party application <NUM> may include one or more computing systems <NUM>. As such, the principles described herein are implemented in an environment including one or more computing systems that are configured to communicate with each other directly or indirectly via computer networks. In particular, the principles described herein may be implemented at an identity provider <NUM> to provide service providers <NUM> an improved claim policy configuration and verification functions that are protocol agnostic, which improves the functions of the computing systems of both the identity provider <NUM> and the service provider <NUM>.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, an some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

Claim 1:
A computing system (<NUM>) comprising:
one or more processors (<NUM>); and
one or more computer-readable media (<NUM>) having thereon computer-executable instructions that are structured such that, when executed by the one or more processors (<NUM>), cause the computing system (<NUM>) to perform at least:
generate (<NUM>) one or more protocol-agnostic identity claim policies (<NUM>, <NUM>); and
apply (<NUM>) at least one of the one or more identity claim policies (<NUM>, <NUM>) to one or more applications (<NUM>-<NUM>), each of the one or more applications (<NUM>-<NUM>) implementing a particular identity authentication protocol that is one of a plurality of identity authentication protocols; and
test (<NUM>) at least one of the one or more identity claim policies after applying the at least one identity claim policy to the one or more applications;
the applying (<NUM>) the at least one identity claim policy (<NUM>, <NUM>) comprising:
for each of the one or more applications,
determining (<NUM>) the identity authentication protocol that is implemented by the corresponding application; and
based on the determined identity authentication protocol, determining (<NUM>) one or more identity claims (200B,300C) of the corresponding application (<NUM>-<NUM>) that corresponds to the at least one identity claim policy (<NUM>, <NUM>); and
the testing the at least one identity claim policy that is applied to a particular application comprising:
setting up a test framework (<NUM>) into the particular application for generating test requests; and
for each of the plurality of protocols:
generating a test request for accessing the test application;
receiving (<NUM>)a security token of the corresponding protocol, the security token including one or more identity claims;
decoding the one or more identity claims contained in the security token; and
displaying the decoded one or more identity claims.