First time user enrollment in a federation environment, when the credential used is a X.509 certificate issued from a Public Key Infrastructure (PKI), often brings unique challenges. This blog post explores those challenges and some potential approaches to addressing them.
The enrollment concerns that arise when using X.509 certificates in a federation are driven by the two ways that an X.509 credential can be validated by the Relying Party (RP). Each authentication approach, PKI Indirect Authentication and PKI Direct Authentication, has a bearing on the user information that is available to the RP after the credential has been validated.
PKI Indirect Authentication
This is a typical federation scenario. The key points to keep in mind are:
- A trust relationship exists between the CA and the CSP
- CSP validates the X.509 certificate, which includes trust path discovery and trust path validation
- The CSP does some manner of protocol mediation (e.g. converts the results of the authentication into a SAML Authentication Assertion) to convey information to the RP
- The policies of Trust Domain A and Trust Domain B are the same or a formal mapping has been done between the policies such that the “Trust Framework A” and “Trust Framework B” are considered equivalent
This is all standardized goodness on the authentication front. The enrollment challenge arise in the scarcity of user information that the CSP is able to parse from the certificate and send to the RP. From a certificate, you can typically parse the Subject DN or other person information (e.g. A FASC-N in the case of a PIV Card or a UUID in the case of the PIV-I Card) as well as information about the issuing entity. But as I discussed in “If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later. Redux”, attributes such as Address, DOB, and SSN, which are typically used to resolve an asserted identity to a RP record, are typically not present on the certificate.
In this case a possible solution is predicated on the ability to the CSP to access an authoritative source of information about the certificate holder, and after authenticating the user, “enrich” the assertion that is sent to the RP with additional attributes that would allow for identity resolution. e.g. Send a SAML Authentication AND an Attribute Assertion which contains both a shared identifier and the attributes necessary to uniquely resolve an asserted identity to a RP record. (NOTE: For enrollment purposes, I consider “Holder of Key” to be a variation on this scenario)
PKI Direct Authentication
This scenario arises when the RP has the ability to directly validate the X.509 certificate. The key points to keep in mind are:
- A trust relationship exists between the RP and the CA. Whether that is brokered through some sort of a PKI Bridge construct is irrelevant here
- The RP validates the X.509 certificate, which includes trust path discovery and trust path validation
The enrollment challenge here is the same as before, which is the scarcity of user information that the RP is able to parse from the certificate. The potential solution here is for the RP to initiate a back-channel attribute query to an authoritative source to retrieve the attributes needed for identity resolution. But this approach has multiple dependencies that need to be satisfied in order for successful user enrollment:
- An element that the RP parses from the certificate after validation MUST be able to act as a shared identifier between it and the authoritative attribute source
- Enough information MUST exist in the certificate for the RP to be able to “route” the query to the relevant authoritative attribute source
- Needless to say, the authoritative attribute source MUST have a trust relationship with the RP such that it will respond to the queries
While I can think of some specific and very narrow use cases where enrollment could be successful without corresponding external attribute sources (e.g. The FASC-N is a rich source of data, provided the user base is limited to only PIV Users), I am not sure if this would work in a general use case without one. In particular, without either a corresponding authoritative attribute source to retrieve verified attributes or using an external service to validate attributes that have been self-asserted by the user at the RP, I do not believe that user enrollment can occur at the RP.
I would very much appreciate feedback on this topic and would love to hear about alternative approaches that may exist to address this issue.
- If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later. Redux
- Here Be Dragons - Social Security Number and Federation User Enrollment
- How To Enroll a User, Even When There are No Shared Identifiers
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.