I just finished configuring Oracle Access Manager (OAM) for Common Access Card (CAC) authentication integrated with Axway’s Server Validator (SV)Plugin ( I will blog about this in another post ) for certificate validation. While discussing this with another engineer on the project he mentioned that this really opened the door for tightly integrating with a lot of their existing partners. I said that while this is great I would prefer to federate with these partners and not have to deal with managing the extra infrastructure components as well has having to manage several trusted certificates provided by the partners (with intermediate certificates there were about 6 just for this partner alone … I am trying to picture how that scales for each new partner). I freely admit that I am biased towards Federation. I am totally sold-out on the benefits of having the Identity Provider (IdP) take care of credentialing and authentication and the Service Provider (SP) can focus on the applications. His point in preferring to authenticate locally with CAC (vs via Federation) was that by doing so we somehow offer a better user experience. I think you can also make the argument that a particular, potential IdP maybe not have Federation capabilities (this won’t always be the case IMO). Do you think that you can achieve the same Level of Assurance (LoA) by using Federation instead of authenticating at the SP? (SAML, OpenID or OpenID Connect)
I’d like to crowd-source this discussion and see if we can put together some good arguments for/against either side. Please RT and comment if you have thoughts/opinions on this.
You can get a much better user experience and at least equivalent LoA by doing federation as opposed to checking everything yourself. What’s a better user experience than them logging in to their own known and trusted provider instead of some backwater service provider? Shouldn’t we be teaching users not to throw their credentials directly at whoever asks? And I’ll add, it’s really pretty silly in this day and age to think that you’ve got to check everything yourself locally. The PKI forest will never scale, especially over time. You’ve got to keep on top of the certificate revocations for everybody, forever, in order for it to actually work. Eventually the system just fills with garbage.
In a connected world, much better to have a system where you can have short lived credentialing and let the relying parties call back to the IdP, through a SAMLy message or an OpenID Connect RESTy call, in real time when you need to. Server needs a public new key? OK, just put one on the server. Everyone else just discovers it next time they try to validate something that server signed. Need it to scale? Put known cache timeouts on things to balance your max rotation time with your cache hits.
When you let the internet do the hard work for you, many of the infrastructure problems go away.
Absolutely! PIV cards bring the headaches of not just verifying the certificate, but linking it to user account information, verifying CRLs and getting additional data such as group memberships/claims/pick your favorite az word. So much easier to just use SAML2 to provide that data in a signed and encrypted assertion.
I agree with Justin R. Federation is a much better option when it comes to the end-user experience. And, for service providers who don’t support standards, vendors often have some kind of credential storage capability that will allow you to add SPs with non-standard interfaces, thus providing a wider net of access to user applications.
Here is my ‘business side’ take on this discussion… Biggest question for me is ‘how much trust do you have in your IdP’? Anything above LoA 1 and you need to have IdPs that are reliable, trustworthy and aligned with your business or industry. Facebook Connect for access to health records? No thanks.
The other point I’d make is around your desired relationship with the users of your apps/site. If these users are a critical part of your organization’s existence (e.g. students at a university/college), you are likely in the identity business anyway – whether you like it or not. In that case, you might as well provide authentication and maybe even act as an IdP for others.