Using External IDPs

Introduction

As the neo-security article outlines, each part of the identity architecture has a role to play. The Curity Identity Server can act as the Authentication Service, the Token Service and the User Management Service. Each part has its own set of capabilities and strengths.

Commonly organizations already have an Identity Provider (IdP) that is responsible for user authentication, including on-boarding and user self service. This could be IDaaS services such as Azure AD, Okta or Entrust IDaaS. This fits very well with how the Curity Identity Server was designed. The authentication service can be used to federate up to an external IdP for user login, and then back to continue the OAuth or OpenID Connect flow at Curity. This provides the best of two worlds as it enables the organization to utilize the full power of Curity's token service, as well as orchestrating the login flow running Authentication Actions after the IdP has authenticated the user.

Federate but Orchestrate

The Curity Authentication Service is a multiplexer of sorts. It was designed to be able to connect with any authentication method -- either standalone or combined with further authentication options.

After each authentication method completes the Authentication Service provides a framework for orchestration implemented using Authentication Actions. These are combined in a pipeline (with possible sub-pipelines and branches) that have the power to do the following things:

• Approve the authentication
• Fail the authentication if certain conditions aren't met
• Ask the user to authenticate with some other method
• Prompt the user for interaction
• Redirect the user to another site and resume once the user is redirected back
• Modify the authentication result, e.g., update, add or remove attributes that are the result of authentication

With these options a large toolbox can be built. The actions shipped with the product operate in all areas above and can do things such as denying access if the user has travelled too fast between logins (geo velocity) or request a second factor based on user opted-in settings and more.

Collaborative Adaptive Authentication

The authentication actions can act on attributes returned by an external up-stream IdP to decide if additional security measures are needed, or transform the resulting attributes into something system specific. This makes it possible to use information from the IdP to perform collaborative adaptive authentication where the IdP can hand off its current result/state in the resulting attributes and allow the Curity Authentication Service to make decisions about whether more measures should be taken to assert the user's identity.

The event framework in the server can be used to feed user authentication information back up to the IdP for it to obtain more knowledge about the authentication session to adapt to the next login's requirements.

The Power of OAuth and OpenID Connect

The Curity Token Service is an industry-leading implementation of OAuth and OpenID Connect. This means that all the advanced features of the standards can be used irrespective of the authentication process chosen. For example, a financial-grade setup using PAR, JARM and message-level encryption can be utilized without the upstream IdP needing additional features.

Claims and Scopes

One of the most important aspects is that by using the Curity Token Service, the APIs and clients still can benefit from the highly customizable tokens enabled via the claims subsystem. As the upstream IdP returns attributes in the authentication result, these can be incorporated in the regular claims mapping performed when issuing tokens as any other claims source.

The attributes can be transformed and combined with attributes from other sources such as databases or APIs to form claims. The token issuance is fine grained and can be customized on a per client basis if needed, providing custom tokens for special clients.

Conclusion

Using external IdPs (including IDaaS platforms) with the Curity Identity Server is supported by design and is architecturally sound in many scenarios. It does not prohibit or limit the power of either the Authentication Service or the Token Service.