0

I am going to talk in terms of SAML but I'm not fussed about the protocols.

There will be a Federation Provider (FP) that trusts a number of external and 1 internal Identity Providers (IdP). The applications (SP) will in turn trust the FP. The SPs are a mixture of Java and .Net. The external IdPs won't know the permissions and claims to add to their security tokens for use by the SPs but the local IdP will. I need to associate the appropriate roles, permissions and groups to the identity so an SP can grant or deny access appropriately.

I can see 2 options:

  1. The FP maps the external identities to local ones and does claims augmentation by querying the local IdP and enhancing the security token with the appropriate claims before passing to the SP.
  2. The SP queries the local IdP and extracts the permissions that way.

What are the common patterns in this area?

Bonus points for suggesting products that support either of these scenarios (note: not a product recommendation which would be subjective, just a statement of capability)

Update: I have been impressed with the capabilities offered by Shibboleth SP, particularly the way it operates at the web server level freeing the application from the responsibility for handling SAML.

https://shibboleth.net/products/service-provider.html

Peter Kelley
  • 2,350
  • 8
  • 26
  • 46

2 Answers2

2

We have built something similar to this, although our solution may not meet yours. Our model is a hub and spoke federation model where our hub maintains information about all users who have authenticated at least once in the federation. We provision the users on demand (ie: upon authentication) and allow augmentation of the users' data in the hub by administrators. We hide the very heterogeneous collection of authentication systems (SAML, CAS, LDAP, OpenID Connect) from the SPs that use the hub and normalize the claims that are passed to the SPs. In general, on the IDP side of the hub, the hub acts as a service provider; on the SP side of the hub, the hub acts as an identity provider. We've found that isolating the variability of the IDPs from the SPs is an effective abstraction for our SPs.

judielaine
  • 188
  • 8
  • Are you able to share what products you used to achieve this? – Peter Kelley May 29 '15 at 01:47
  • 1
    We've pretty much built from scratch as our scale and requirements were not represented in off the shelf code. I understand that the Irish federation has released federation metadata management opensource code, but that isn't the hub functionality. – judielaine May 29 '15 at 23:03
0

The architecture you describe is a common design pattern for a product (set of applications) hosted on the internet, where your users/partners have the option to provide an IdP or utilize your IdP for authentication. Many regulated industries require that Authorization be performed by the party providing the web applications and services. Since you will be doing authorization and adding attributes, you will need to manage all the user identities and have information provisioned for those users into your local database. Upon receipt of the authentication assertion, then it will be augmented with authorization information from your local database.

There are many on-premise Federation Solutions on the market today that perform the function you have described. I am going to focus on a SAML solution here, although there are other options for federation protocol. A couple of terms so the answer is more clear. The Identity Provider(s) will be the components that issue SAML assertions and only perform authentication, the Service Provider (SP) will be the component in your network to request/receive SAML assertions as well as augment the assertion with authorization data from your local database, and web applications to receive identity tokens, which are your applications.

Within the context of your network you will have a federation server that acts as the SP using the SAML protocol to all the desired IdPs. This component is essentially a federation hub. All of your web applications will communicate with this federation hub. An IdP Discovery service will be needed to determine where to route the SAML Request, which can be implemented within the federation hub, or in each application. My preference is to have the IdP Discovery as part of the federation hub. There are a couple of options for discovery such as using URLs or having a selection interface displayed to the user which is driven by the type of requirements and use case (workforce, business partner, customer). When your web application invokes the federation hub and associated IdP Discovery, then the SAML request will be sent to the appropriate IdP. Upon receipt of the SAML response, the assertion will be validated and subject retrieved. This is where some options come into play based on the vendor and business requirements you have for the solution. Products that act in the SP role as a federation hub that receive SAML assertions generally will have some type of plug-in interface or configuration that allows you to query for attributes from your local user database (or a directory service). Once all the data is combined, then a last mile integration occurs, either using SAML protocol, vendor protocol, or web service to the federation hub to get all the identity information. Since you have requested product that meets this use case, I have worked extensively with PingFederate by Ping Identity that will solve what you are looking to do.

Eric U.
  • 356
  • 1
  • 3