A recent research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-month total since 2008.
Gartner predicts by 2020, 60% of all digital identities interacting with enterprises will come from external identity providers.
I have written two blog posts in detail highlighting the need for an Identity Bus.
The objective of this blog post is to define the high-level requirements for the Identity Mediation Language. Your thoughts/suggestions are extremely valuable and highly appreciated to evolve this into a language where the global identity management industry will benefit.
1. Transform identity tokens from one protocol to another.
For example, the Identity Mediation Language should have the provision to the transform an incoming SAML request into an OpenID Connect request, and then the OpenID Connect response from the Identity Provider into a SAML response.
2. The language should have the ability define a handler chain in inbound-authentication-request flow, outbound-authentication-request flow, outbound-authentication-response flow, inbound-authentication-response flow and any of the major channels identified as this specification evolves.
3. The language should define a common syntax and semantics, independent from any of the protocols.
Having a common a common syntax and semantics for the language, independent from any of the specific protocols will make it extensible. Support for specific protocols should be implemented as handlers. Each handler should be aware of how to translate the common syntax defined by the language to its own on syntax - and how to process them in a protocol specific manner.
Following is a sample configuration (which must evolve in the future). Language is not coupled to any implementations. There can be global handlers for each protocol, but then again, should be able to override in each request flow if needed.
{
"inbound-authentication-request" :
{ "protocol": "saml",
"handler" : "org.wso2.SAMLAuthReqRespHandler"
},
"outbound-authentication-request" :
{ "protocol": "oidc",
"handler" : "org.wso2.OIDCAuthReqRespHandler"
}
}
4. The language should have the provision to define a common request/response path as well as override it per service provider.
5. The language should have the provision to identify the service provider by a unique name or by any other associate attributes. These attributes can be read from incoming transport headers or from the Identity Token itself. If read from the ID token, the way to identify that attribute must be protocol agnostic. For example, if the incoming ID token is a SAML token, then - if we need to identify the issuer from an attribute in the SAML token, the language should define it as an XPATH, with out using any SAML specific semantics.
6. The language should have the provision to define, whether an incoming request is just a pass-through.
7. The language should have the provision to define, which transport headers should be passed-through to outbound-authentication-request path.
8. The language should have the provision to define, which transport headers needs to be added to the outbound-authentication-request path.
9. The language should have the provision to log all the requests and responses. Should be able to configure logging per service providers. Log handler should be configurable, per service provider. Due to PCI compliance requirements we may not be able to log the complete message, all the time.
10. The language should have provision to retrieve attributes and attribute metadata, required by a given service provider, via an attribute handler. Also - it should have the provision to define attribute requirements inline.
11. The language should have provision to define, authentication requirements per service providers. The authentication can be using one more - local authenticators, federated authenticators or federated authenticators. The local authenticators will authenticate the end user, using a local credential store. The federated authenticators will talk to an external identity provider to authenticate users. The request path authenticators will authenticate users from the credentials attached to request itself.
12. The language should have the provision to define, multiple-option and multiple-steps authentication, per service provider. In multiple-option scenario, the relationship between in authenticators is an OR. That means, user needs to authenticate only using a single authenticator. With multiple-steps, the relationship between steps is an AND. User must authenticate in successfully in each step.
13. The language should have the provision to define, multiple-option and multiple-steps authentication, per user. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role, then he must authenticate with multi-factor authentication.
14. The language should have the provision to define, multiple-option and multiple-steps authentication, per user, per service provider. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role and if he accesses a high-privileged application then he must authenticate with multi-factor authentication, if the same person accesses the user profile dashboard, then multi-factor authentication is not required.
15. The language should not define any authenticators by itself.
16. The language should have the provision to define, authenticator sequences independently and then associate them to an authentication request path, just by a reference. Also should have the ability to define them inline.
17. The language should support defining requirements for adaptive authentication. A service provider may have a concrete authenticator sequence attached to it. At the same time, the language should have the provision to dynamically pick authenticator sequences in a context aware manner.
18. The language should have the provision to define, per service provider, authorization policies. Authorization policy may define the criteria under which an end-user can access the given service provider. Only if its satisfied by the authenticated user, the identity provider should send back the authentication response.
19. The language should have the provision to define how to transform a claim set obtained from an identity provider to a claim dialect specific to a give service provider. This can be a simple one to one claim transformation, for example http://claims.idp1.org/firstName --> http://claims.sp1.org/firstName, or a complex claim transformation like, http://claims.idp1.org/firstName + http://claims.idp1.org/lastName --> http://claims.sp1.org/fullName. The language should have the provision to do this claim transformation from inboudAuthenticationRequest flow to outboundAuthenticationRequest/localAuthenticationRequest flow and from outboundAuthenticationResponse/localAuthenticationResponse flow to inboundAuthenticationResponse flow.
20. The language should have the provision to authenticate service providers, irrespective of the protocol used in the inboundAuthenticationRequest.
21. The language should have the provision to accept, authentication requests, provisioning requests, authorization requests, attribute requests and any other types of requests from the service provider. The language should not be just limited to above four types of requests and must have the provision to extend.
22. The language should define a way to retrieve identity provider and service provider metadata.
23. The language should have the provision to define rule-based user provisioning per service provider, per identity provider or per user - and per attributes associated with any of the above entities. For example, if the user is provisioned to the system via foo service provider and if his role is sales-team, provision the user to salesforce. Another example could be, provision everyone authenticated against the Facebook identity provider to a internal user store.
24. The language should have the provision to indicate to a policy decision point (for access controlling), from which service provider the access controlling request is initiated from and also with the other related metadata.
25. The language should have the provision to the specify just-in-time provisioning requirements per service provider, per identity provider or per user - and and per attributes associated with any of the above entities.
26. The language should have the provision to specify, per service provider - the user
store and the attribute store for local authentication and to retrieve user attributes locally.
27. The language should have the provision to specify an algorithm and a handler for force authentication for users already logged into the identity provider. There can be a case where user is already authenticated to the system with a single factor - when the same user tries to log into a service provider which needs two-factor authentication, then the algorithm handler should decide whether to force user authentication - and if so at which level. There can be an algorithm handler defined at the global level and also per service provider request flow.
28. The language should have the provision to specify a home-realm-discovery handler, per service provider. This handler should know how to read the request to find out relevant attributes that can be used to identify the authentication options for that particular request.
29. The language should have the provision to define attribute requirements for out-bound provisioning requests.
30. The language should have the provision to define claim transformations prior to just-in-time provisioning or out-bound provisioning.
31. The language must have the provision to define how to authenticate to external endpoints. The language should not be coupled into any specific authentication protocol.
Gartner predicts by 2020, 60% of all digital identities interacting with enterprises will come from external identity providers.
I have written two blog posts in detail highlighting the need for an Identity Bus.
- Connected Identity : Benefits, Risks & Challenges
- Borderless Identity: Managing Identity in a Complex World
The objective of this blog post is to define the high-level requirements for the Identity Mediation Language. Your thoughts/suggestions are extremely valuable and highly appreciated to evolve this into a language where the global identity management industry will benefit.
1. Transform identity tokens from one protocol to another.
For example, the Identity Mediation Language should have the provision to the transform an incoming SAML request into an OpenID Connect request, and then the OpenID Connect response from the Identity Provider into a SAML response.
2. The language should have the ability define a handler chain in inbound-authentication-request flow, outbound-authentication-request flow, outbound-authentication-response flow, inbound-authentication-response flow and any of the major channels identified as this specification evolves.
Having a common a common syntax and semantics for the language, independent from any of the specific protocols will make it extensible. Support for specific protocols should be implemented as handlers. Each handler should be aware of how to translate the common syntax defined by the language to its own on syntax - and how to process them in a protocol specific manner.
Following is a sample configuration (which must evolve in the future). Language is not coupled to any implementations. There can be global handlers for each protocol, but then again, should be able to override in each request flow if needed.
{
"inbound-authentication-request" :
{ "protocol": "saml",
"handler" : "org.wso2.SAMLAuthReqRespHandler"
},
"outbound-authentication-request" :
{ "protocol": "oidc",
"handler" : "org.wso2.OIDCAuthReqRespHandler"
}
}
4. The language should have the provision to define a common request/response path as well as override it per service provider.
5. The language should have the provision to identify the service provider by a unique name or by any other associate attributes. These attributes can be read from incoming transport headers or from the Identity Token itself. If read from the ID token, the way to identify that attribute must be protocol agnostic. For example, if the incoming ID token is a SAML token, then - if we need to identify the issuer from an attribute in the SAML token, the language should define it as an XPATH, with out using any SAML specific semantics.
6. The language should have the provision to define, whether an incoming request is just a pass-through.
7. The language should have the provision to define, which transport headers should be passed-through to outbound-authentication-request path.
8. The language should have the provision to define, which transport headers needs to be added to the outbound-authentication-request path.
9. The language should have the provision to log all the requests and responses. Should be able to configure logging per service providers. Log handler should be configurable, per service provider. Due to PCI compliance requirements we may not be able to log the complete message, all the time.
10. The language should have provision to retrieve attributes and attribute metadata, required by a given service provider, via an attribute handler. Also - it should have the provision to define attribute requirements inline.
11. The language should have provision to define, authentication requirements per service providers. The authentication can be using one more - local authenticators, federated authenticators or federated authenticators. The local authenticators will authenticate the end user, using a local credential store. The federated authenticators will talk to an external identity provider to authenticate users. The request path authenticators will authenticate users from the credentials attached to request itself.
12. The language should have the provision to define, multiple-option and multiple-steps authentication, per service provider. In multiple-option scenario, the relationship between in authenticators is an OR. That means, user needs to authenticate only using a single authenticator. With multiple-steps, the relationship between steps is an AND. User must authenticate in successfully in each step.
13. The language should have the provision to define, multiple-option and multiple-steps authentication, per user. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role, then he must authenticate with multi-factor authentication.
14. The language should have the provision to define, multiple-option and multiple-steps authentication, per user, per service provider. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role and if he accesses a high-privileged application then he must authenticate with multi-factor authentication, if the same person accesses the user profile dashboard, then multi-factor authentication is not required.
15. The language should not define any authenticators by itself.
16. The language should have the provision to define, authenticator sequences independently and then associate them to an authentication request path, just by a reference. Also should have the ability to define them inline.
17. The language should support defining requirements for adaptive authentication. A service provider may have a concrete authenticator sequence attached to it. At the same time, the language should have the provision to dynamically pick authenticator sequences in a context aware manner.
18. The language should have the provision to define, per service provider, authorization policies. Authorization policy may define the criteria under which an end-user can access the given service provider. Only if its satisfied by the authenticated user, the identity provider should send back the authentication response.
19. The language should have the provision to define how to transform a claim set obtained from an identity provider to a claim dialect specific to a give service provider. This can be a simple one to one claim transformation, for example http://claims.idp1.org/firstName --> http://claims.sp1.org/firstName, or a complex claim transformation like, http://claims.idp1.org/firstName + http://claims.idp1.org/lastName --> http://claims.sp1.org/fullName. The language should have the provision to do this claim transformation from inboudAuthenticationRequest flow to outboundAuthenticationRequest/localAuthenticationRequest flow and from outboundAuthenticationResponse/localAuthenticationResponse flow to inboundAuthenticationResponse flow.
20. The language should have the provision to authenticate service providers, irrespective of the protocol used in the inboundAuthenticationRequest.
21. The language should have the provision to accept, authentication requests, provisioning requests, authorization requests, attribute requests and any other types of requests from the service provider. The language should not be just limited to above four types of requests and must have the provision to extend.
22. The language should define a way to retrieve identity provider and service provider metadata.
23. The language should have the provision to define rule-based user provisioning per service provider, per identity provider or per user - and per attributes associated with any of the above entities. For example, if the user is provisioned to the system via foo service provider and if his role is sales-team, provision the user to salesforce. Another example could be, provision everyone authenticated against the Facebook identity provider to a internal user store.
24. The language should have the provision to indicate to a policy decision point (for access controlling), from which service provider the access controlling request is initiated from and also with the other related metadata.
25. The language should have the provision to the specify just-in-time provisioning requirements per service provider, per identity provider or per user - and and per attributes associated with any of the above entities.
26. The language should have the provision to specify, per service provider - the user
store and the attribute store for local authentication and to retrieve user attributes locally.
27. The language should have the provision to specify an algorithm and a handler for force authentication for users already logged into the identity provider. There can be a case where user is already authenticated to the system with a single factor - when the same user tries to log into a service provider which needs two-factor authentication, then the algorithm handler should decide whether to force user authentication - and if so at which level. There can be an algorithm handler defined at the global level and also per service provider request flow.
28. The language should have the provision to specify a home-realm-discovery handler, per service provider. This handler should know how to read the request to find out relevant attributes that can be used to identify the authentication options for that particular request.
29. The language should have the provision to define attribute requirements for out-bound provisioning requests.
30. The language should have the provision to define claim transformations prior to just-in-time provisioning or out-bound provisioning.
31. The language must have the provision to define how to authenticate to external endpoints. The language should not be coupled into any specific authentication protocol.