Core Security Patterns Weblog
Practical security facts and fun….off the record
4
In a typical Single Sign-On (SSO)/Federation scenario using SAML, the Service Provider (SP) initiates the user authentication request using SAML AuthnRequest assertion with an Identity Provider (IDP). The IDP authenticates the principal and returns a SAML AuthnStatement assertion response confirming the user authentication. If the user is successfully authenticated, the SP is required to have the subject’s profile attributes of the authenticated principal for making local authorization decisions. To obtain the subject’s profile attributes (ex. organization, email, role), the SP initiates a SAML AttributeQuery request with the target IDP. The IDP returns a response SAML AttributeStatement assertion listing the name of the attributes and the associated values. Using the subject’s profile attributes, the SP can perform authorization operations.
Ofcourse, it looks simple…here is the complexity – Last two weeks I spent on building a Proof-of-Concept that conforms to HSPD-12 Back-end Attribute Exchange specifications and SAMLv2 Attribute Sharing Profile for X.509 Authentication based systems (Both specifications are mandated as part of Federal Identity, Credential and Access Management (ICAM) initiative of Federal CIO Council). I had been experimenting with an Identity Federation scenario that makes use of Smartcard/PKI credentials – Card Authentication Key (CAK)/X.509 Certificate on a PIV card authenticates a PKI provider (using OCSP) and then using its X.509 credential attributes (Subject DN) for looking up off-card user attributes from an IDP (that acts as an Attribute Authority). The IDP provides the user profile attribute information to the requesting SP. In simpler terms, the SP initiated X.509 authentication directly via OCSP request/response with a Certificate Validation Authority (VA) of a Certificate Authority (CA). Upon successful authentication, the SP initiates a SAML AttributeQuery to the IDP (which acts as an Attribute Authority), the SAML AttributeQuery uses the SubjectDN of the authenticated principal from the X.509 certificate and requests the IDP to provide the subject’s user profile attributes.
Using Fedlet for SAML X.509 Authentication based Attribute Sharing
SAML Attribute Exchange for X.509 based Authentication
Fedlet is a lightweight SAMLv2 based Service Provider (SP) implementation (currently part of Sun OpenSSO 8.x and sooner to be available in Oracle Identity Federation) for enabling SAMLv2 based Single Sign-On environment. In simpler terms, Fedlet allows an Identity Provider (IDP) to enable an SP that need not have federation implemented. The SP plugs in the Fedlet to a Java/.NET web application and then ready to initiate SAML v2 based SSO authentication, authorization and attribute exchanges. A Fedlet installed and configured with a SP can set up to use multiple IDPs where select IDPs can acts as Attribute Authorities. In this case, the Fedlet need to update its configuration with the IDP Metadata configuration (such as entity ID, IDP Meta Alias, Attribute Authority Meta Alias – same as IDP ). In addition, the Fedlets are capable of performing XML signature verification and decryption of responses from the IDP must identify the alias of signing and encryption certificates.
Here is the quick documentation, which I referred for putting together the solution using Fedlets for SAMLv2 Attribute Sharing for X.509 based authentication scenarios. In case, if you want your Service Provider to use OpenSSO for PIV/CAC based certificate authentication, you may refer to my earlier entry on Smartcard/PKI authentication based SSO (Using OpenSSO). Besides that you should be good to test-drive your excercise. Ofcourse, you can use Fedlets for Microsoft .NET service providers but it was’nt in my scope of work !
In case of SP requiring to fetch multiple user profile attributes you may also choose to use SPML based queries (SPML Lookup/Update/Batch Request/Response) to an Identity Manager (acting as Attribute Authority) – assuming it facilitates an SPML implementation). If you are looking for a solution that requires user profile attributes after a single-user X.509 authentication, then SAML Attribute query should help fetching a single user profile of an authenticated principal !
Are you tired of the high-level SPML content floating around the web from couple of analysts with no practical guidance ! If you are a practical guy..who want to explore SPML, here is something that you may find worth test-driving for SPML 1.0 amd SPML 2.0 based provisioning operations.
I had been using SPML using Sun IDM 7.0 for a while now. Most frequently, I forget the steps for configuration and also did’nt have the patience of going through the documentation (Frankly..I’m bit lazy). So, I ended up doing my crazy way and here is the cheat sheet of the steps required.
Configuring SPML Web Services Endpoint in Sun IDM
1. Make sure Sun IDM is deployed and tested to run in your Web container environment (My choice would be Glassfish on Solaris 10). Sorry, I am not a Windows guy
2. Open a terminal, set your JAVA_HOME and WSHOME environment variables
bash-3.00# export JAVA_HOME=export JAVA_HOME=/usr/java
bash-3.00# export WSHOME=/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm
bash-3.00# export
bash-3.00# export DISPLAY=<your host_name>:0.0
bash-3.00# cd /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/bin
bash-3.00# ./lh console
3. Configure SPML 1.0 and SPML 2.0 objects by importing them.
Configurator> import -f /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/sample/spml.xml
Added TaskDefinition:SPMLRequest
Added Configuration:SPML
Added Configuration:SPMLPerson
Added Configuration:SPMLRole
Added Configuration:SPMLResourceGroup
Added Configuration:BasicUser
Added Configuration:Empty
Added Configuration:SPMLviewtest1
Added Configuration:SysInfoForm
Configurator> exit
Configurator> import -f /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/sample/spml2.xml
Added TaskDefinition:SPML2Request
Updated Configuration:User Extended Attributes
Added Configuration:SPML2
Added Configuration:spml2PersonForm
Configurator> exit
4. Set the Username/Password properties in Waveset.properties file.
bash-3.00# vi /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/config/Waveset.properties
Add the following to the end of Waveset.properties file:
soap.username=configurator
soap.password=configurator
4. Restart your Application Server:
bash-3.00# /opt/SUNWappserver/bin/asadmin stop-domain domain1
bash-3.00# /opt/SUNWappserver/bin/asadmin start-domain –user admin domain1
5. Test your SPML Web services connection. The following command will launch “SPML Monitor” Java application.
bash-3.00# ./lh spml
Sample code
Here is my code for testing (both SPML 1.0 and SPML 2.0), just compile and run it.
Enjoy !
Last week, I was at RSA Conference and I joined a panel with Mark Diodati (Burton Group) and Sampo Kellomaki (Symlabs) to discuss interoperable Identity provisioning ! I delved into SPML 2.0 and highlighted the strategies of using SPML 2.0 for interoperable provisioning. Here is the link to our slides – Interoperable Identity Provisioning in a Distributed World (With emphasis on SPML).
I had multiple opportunities to work on SPML based user-provisioning with Sun Java System Identity Manager. I found SPML as a very compelling standard, it worked as piece-of-cake on Sun IDM that certainly simplified my efforts on representing provisioning requests intended for creating, modifying, canceling, deleting, enabling, disabling, searching user accounts and associated access control privileges with multiple resources. Naturally I had the passion to dig deeper into SPML 2.0 ! I briefly involved with OASIS SPML TC forums and their discussions… unlike other standard efforts I am quite convinced about SPML gaining strong adoption as a de-facto standard in the user-provisioning industry and sooner it is also expected to play a vital role in enabling identity federation (yes, seriously!). We do know well, SPML helps to initiate XML-based provisioning/de-provisioning processes from the identity provider to its target service providers. This means SPML does allow users to bypass out-of-band account creation requirements using provisioning/synchronization mechanisms from LDAP, database and other user repositories. By working together with SAML, SPML can make use of SAML assertions by facilitating a trust model in which senders and receivers using SPML messages agree upon the context of a predefined unique user identifier represented by a SAML assertion. To be more precise, the SAML assertion allows users to qualify a subject, against which a provisioning request is targeted.
Lately “Federated Provisioning Profile” (SAML 2.0 Profile for SPML), a supporting profile effort, is in progress as part of OASIS Security Services (SAML) TC, which addresses the use of SAML within SPML messages. The Federated Provisioning Profile focuses on the usecase requirements, facilitating the use of SPML provisioning in identity federation where SPML messages can make use of SAML assertions as provisioning data and on-demand/just-in-time bulk user provisioning between an identity provider (IdP) and a service provider (SP). It is promising, but I am not sure where this effort stands now !
Back to top