To implement a federated solution where the consumer of a service can select which attribute is sent from the identity provider to the service provider as an assertion write a custom IDPAttributeMapper . The getAttributes() method takes the OpenSSO SSOToken as one of its parameters. From this, you can determine who the end user is, pull the correct attributes for that user and return the values as an attribute list. The identity provider will take the attributes and send them to the service provider as part of a SAMLv2 assertion.
Once you've finished, check out the video for the Academy Award-winning song from the movie Once. Excellent film about two people Falling Slowly in love. The love segued into real life until last night when I read that Glen Hansard and Marketa Irglova were no longer a couple. Worse things have happened but they were a sweet couple in the film.
The SAMLv2 Name Identifier Management Profile documents how an identity provider and a service provider might inform each other of changes to the identifier that they reference when communicating about a particular identity. The various OpenSSO ManageNameID (MNI) JSP provide a way to change SAMLv2 name identifiers or terminate mappings between identity provider accounts and service provider accounts. For example, after establishing a name identifier for use between providers when referring to an identity in SAMLv2 communications, an identity provider may want to change the value and/or format. The identity provider will notify service providers of the change by sending them a ManageNameIDRequest. A service provider might also use this message type to register or change the SPProvidedID value (included when the underlying name identifier is used to communicate with it) or to terminate the use of a name identifier between itself and the identity provider.
Following is a procedure that can be used to test the profile using OpenSSO. In the example procedure, maple.sun.com is the identity provider and honey.sun.com is the service provider.
Initiate single sign-on and account linking (federation) from the service provider side using http://honey.sun.com:80/opensso/saml2/jsp/spSSOInit.jsp?
metaAlias=/sp&idpEntityID=maple.sun.com.spSSOInit.jsp is used to initiate single sign-on and federation on the service provider side. Because metaAlias and idpEntityID are defined, the request is created and sent to the identity provider. This links the two accounts and creates a name identifier to be used by the providers to refer to the identity during communications. Both providers keep the name identifier in the user's profile which makes the format persistent.
Log in to the identity provider host machine and the service provider host machine as root.
Run ldapsearch -h maple -D "cn=directory manager" -w password -p 389 -b "dc=sun,dc=com" "uid=\*" sun-fm-saml2-nameid-info sun-fm-saml2-nameid-infokey on each host machine to view the values for the sun-fm-saml2-nameid-info and sun-fm-saml2-nameid-infokey properties.
On the identity provider side, sun-fm-saml2-nameid-info will have a value similar to
On the service provider side, sun-fm-saml2-nameid-info will have a value similar to
null|honey.sun.com|SPRole|falsesun-fm-saml2-nameid-info is used to store all information related to the name identifier. The value is formatted as:
hosted_entity_id : entity id for this hosted entity
remote_entity_id : entity id for the remote entity
idp_nameid : name identifier for the IDP
idp_nameid_qualifier: nameid qualifier for the IDP
idp_nameid_format : nameid format for the IDP
sp_nameid : name identifier for the SP/Affiliation
sp_nameid_qualifier : nameid qualifier for the SP/Affiliation
hosted_entity_role : SPRole or IDPRole, useful when one entity could be IDP and SP at same time.
is_affiliation : true for affiliation, false otherwise
On the identity provider side, sun-fm-saml2-nameid-infokey will have a value similar to
On the service provider side, sun-fm-saml2-nameid-infokey will have a value similar to
KFXSFabPdkOOhRpkkW8Aj5Etnq2osun-fm-saml2-nameid-infokey is used to search an LDAP data store for better performance, when that type of data store is used. The user that binds to the LDAP data store must have read/write/search/compare permission to this attribute. You must also must make sure that the equality type index is added to the data store. The value is formatted as:
hosted_entity_id : entity id for this hosted entity
remote_entity_id : entity id for the remote entity
idp_nameid : name identifier for the IDP
Terminate the link (defederate) between the user's service provider and identity provider accounts using one of the following URLs referencing spMNIRequestInit.jsp.
Initiate defederation from the service provider using either HTTP-Redirect binding or SOAP binding respectively:
Initiate defederation from the identity provider using either HTTP-Redirect binding or SOAP binding respectively:
After defederation, run the previous ldapsearch command again.
The two properties have no values on both the identity provider and service provider sides.
Federate the user's service provider account and identity provider account again using the URL that references spSSOInit.jsp.http://honey.sun.com:80/opensso/saml2/jsp/spSSOInit.jsp?
Run the previous ldapsearch command again. The two properties have values on both the identity provider and service provider sides again; the value of the name identifier is different from the previous value.
Initiate the creation of a new name identifier using one of the following:
Initiate the creation of a new name identifier from the service provider side using spMNIRequestInit.jsp and the following URL:
Initiate the creation of a new name identifier from the identity provider side using idpMNIRequestInit.jsp and the following URL:
Run the previous ldapsearch command for a third time. The two properties have values on both the identity provider and service provider sides; the value of the new name identifier is different from both of the previous values.
More information on the JSP can be found in the OpenSSO Enterprise 8.0 Administration Guide.
And, in keeping with the sweet theme of the host machine names, here's The Sweet with Fox on the Run. I still smell hamburgers when I hear this song - high school lunches at the coffee shop with a jukebox.
SAMLv2 Assertion Failover, when enabled, redirects a request for an assertion to a second identity provider if the identity provider that initially created the assertion is out of commission. The feature piggybacks on OpenSSO Session Failover configuration by using the same databases. Here is the procedure to configure and test SAMLv2 Assertion Failover.
Deploy 2 instances of OpenSSO Enterprise to act as identity providers and 1 load balancer in front of them.
Set up the entities as a site with servers (using the OpenSSO console) and confirm that the configurations work.
Deploy 1 instance of OpenSSO Enterprise to act as service provider.
On all three provider instances of OpenSSO, enable SAMLv2 Assertion Failover.
Log in to the OpenSSO console as administrator.
Click the Configuration tab.
Click the Global tab.
Click the SAMLv2 Service Configuration link.
Check the box next to Enable SAMLv2 Failover.
Log out of the console.
Configure each server instance of OpenSSO as the appropriate entity provider and member of the same SAMLv2 circle of trust.
Export the entity provider metadata from all three server instances of OpenSSO.
Load the service provider and identity provider metadata on the respective instances of OpenSSO and on the load balancer.
You need to create the metadata for the load balancer. See your load balancer's documentation for more information. Make sure you change the URL values in the load balancer metadata from the OpenSSO instances behind the load balancer to the load balancer URL itself.
Modify the spAssertionConsumer.jsp on the service provider machine to add sleep that allows enough time to shutdown the identity provider on which the request will land. (See step 11.)
Initiate single sign-on using the following URL:
Before proceeding to the next step, run tail on the SAMLv2 debug logs (located in OpenSSO-install-directory/opensso/debug) on the identity provider host machines to see where the single sign-on request lands.
After providing the service provider user credentials, monitor the log and shutdown the identity provider on which the initial single sign-on request landed.
Make sure the user is not federated before shutting down the identity provider. The sleep time added to spAssertionConsumer.jsp in the previous step should allow enough time for this. (See step 9.)
Verify that federation successfully occurs after the identity provider is shutdown. This confirms that assertion failover was successful.
Initiate single logout using the following URL:
Bring the previously shutdown identity provider back up and, once again, initiate single sign-on again using the following URL:
Monitor the log and shutdown the identity provider on which this second single sign-on request landed.
Initiate single logout using the following URL:
A successful logout confirms assertion failover is working.
And now that Assertion Failover has been correctly configured, put your footsies up and check out this live version of The Killers' latest hit - are we Human or are we dancer?
OpenSSO can be integrated with .NET applications. Here are some ways to achieve single sign-on or attribute sharing:
Install the IIS agent to protect the .NET application, and install OpenSSO as the service provider with the .NET application. The identity provider could then achieve single sign-on with the .NET application, and attributes can be passed down, as part of the HTTP header, to the .NET application.
Securely exchange attributes using the .NET client API provided by OpenSSO for integration with the .NET application. This makes use of the SAMLv2 and the Virtual Federation Proxy feature of OpenSSO.
Deploy Active Directory Federation Services as the service provider with the .NET application. OpenSSO would act as the identity provider. Use the WS-Federation protocol to achieve single sign-on with the .NET application.
While ruminating these options, enjoy Cheap and Cheerful from The Kills EXCELLENT third album Midnight Boom.
Here is some information regarding how you might configure OpenSSO sites and servers for a sample SAMLv2 deployment. The requirement in this SAMLv2 deployment is to allow normal users to access OpenSSO via pure SSL and administrative users to access OpenSSO via SSL with certificate authentication. The deployment is a straight forward setup (using two instances of OpenSSO and Glassfish, and one load balancer) except for the following:
The requirement for certificate authentication for one group of users and LDAP authentication for t'other group of users.
The users are split into two domains: one for the identity provider and t'other for the service provider. The identity provider will authenticate, and the service provider will control access using a J2EE policy agent.
The load balancer should be configured with two listening sockets but there should be only one configured Site in OpenSSO. The Site configuration does not need to know both listening sockets as long as the two configured listening sockets (in this example, port 1443 and 2443) point to the same instance of OpenSSO. For this deployment do the following configurations.
On both instances of OpenSSO, under the Configuration --> Servers and Sites tabs in the console, create one New Server for each OpenSSO instance as in:
Create a New Site with your chosen name and a Primary URL that points to the first virtual IP of the load balancer as in https://lb-vip1.server.com:1443/opensso. Click the created Site and add the second virtual IP of the load balancer, https://lb-vip2.server.com:1443/opensso.
Click each server previously created to add the created Site as the value of the Parent Site attribute.
In the first instance of the Glassfish console, configure two listening sockets:
In the second instance of the Glassfish console, configure two listening sockets:
In the load balancer, configure two virtual servers that each points to two different pools:
Virtual Server 1
https://lb-vip1.server.com:1443 points to two different pools:
Virtual Server 2
https://lb-vip2.server.com:2443 points to two different pools:
And from SSL to SSQ, here's Synthecide. Stacey Q was lead singer of this mid-80s Berlin-sounding synth band before she went solo with the Madonna-sounding Two of Hearts. At that point, everyone decided to hate her and she was never heard from again.
The following information was just put in the Sun OpenSSO Enterprise 8.0 Administration Guide but the new version won't be published until next week. Read the information here first. (There might be some changes to this entry based on answers to questions I have sent the engineer. I will update as necessary.)
Requesting Identity Attributes via a SAMLv2 Assertion
The Assertion Query/Request profile specifies a means for requesting attributes (and the corresponding values) from a specific identity profile. A successful response is the return of an assertion containing the requested information. The identity provider acting as the attribute authority uses the com.sun.identity.saml2.plugins.AttributeAuthorityMapper to process queries. This default implementation uses the attribute map table configured in the identity provider's extended metadata; this table maps the requested SAMLv2 attributes to the user profile attributes in the identity data store. (If an attribute map is not configured, no attributes will be returned.)
To set OpenSSO to use a customized attribute mapper implementation, modify the values of the default_attributeAuthorityMapper and the x509Subject_attributeAuthorityMapper properties in the extended metadata of the provider defined as the attribute authority. The default_attributeAuthorityMapper value is used for a standard attribute queries and the x509Subject_attributeAuthorityMapper value is used for attribute queries with an X509 subject. The X509 mapper maps an X509 subject to a user by searching the identity data store for a specified attribute. (The specified attribute is defined as the value of the x509SubjectDataStoreAttrName property in the identity provider extended metadata of the attribute authority.) If the user has the specified attribute and the attribute's value is the same as that of the X509 subject in the attribute query, the user will be used.
Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the providers acting as the attribute requester and the attribute authority is configured.
To send an attribute query from the requester use the method of com.sun.identity.saml2.profile.AttributeQueryUtil.
public static Response sendAttributeQuery(
String attrProfile, String binding)
To construct an AttributeQuery object, use com.sun.identity.saml2.assertion.\*
Requesting a Cached SAMLv2 Assertion
The Assertion Query/Request profile specifies a means for requesting existing assertions using a unique identifier. The requester initiates the profile by sending an assertion request, referenced by the identifier, to a SAMLv2 authority. The SAMLv2 authority processes the request, checks the assertion cache for the identifier, and issues a response to the requester.
NOTE - In the metadata file of the identity provider acting as the SAMLv2 authority, add the following attribute to enable it to store assertions generated in the single sign-on, authentication query or attribute query process.
com.sun.identity.saml2.plugins.AssertionIDRequestMapper is the default implementation used to process the assertion request. To define a customized mapper, change the value of the assertionIDRequestMapper property in the extended metadata of the provider acting as SAMLv2 attribute authority or authentication authority.
To send a request for an assertion from a provider use either of the methods of com.sun.identity.saml2.profile.AssertionIDRequestUtil as below.
If SOAP binding is used, signing is required so the Signing Certificate Alias attribute of the service provider, identity provider, attribute authority and authentication authority metadata must be configured. In order to implement URI binding, you must write a custom mapper so that authenticateRequesterURI will not throw an exception.
Requesting SAMLv2 Authentication Context Information
A SAMLv2 assertion contains information regarding the context of a principal's authentication. The requesting party may require this additional information (for example, the authenticating technology or protocol used) in order to assess the level of confidence they can place in the assertion. To retrieve authentication context information, the service provider issues a query to the authentication authority.
Only SOAP binding is supported for this request And signing is required so make sure the Signing Certificate Alias attribute of the service provider and the authentication authority is configured.
To Configure for Authentication Context Query
Create and load the metadata for the service provider.
Create the metadata for the identity provider using ssoadm and specifying the following additional options.
-C Defines the meta Alias for the hosted authentication authority to be created. The format must be realm name/identifier.
-D Defines the authentication authority signing certificate alias.
-E Defines the authentication authority encryption certificate alias.
For example: ssoadm create-metadata-templ -u amadmin -f /tmp/pw -m /home/user1/tmp/mm -x /home/usr1/tmp/xx -s /idp -a test -r test -C /authna -D test2 -E test2 -y example.com
Add the following attribute to the identity provider metadata file just created. This allows the identity provider to
store assertions generated during the SAMLv2 single sign-on process.
To construct an AuthnQuery object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\*.
Mapping SAMLv2 Name Identifiers
The NameID Mapping Protocol allows a service provider that shares an identifier for a principal with an identity provider to obtain a name identifier for said principal in another format or that is in another federation name space (for example, is shared between the identity provider and another service provider). The requester initiates the profile by sending a NameIDMappingRequest message to the identity provider. After processing the request, the identity
provider issues a NameIdMappingResponse message to the requester.
Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the identity provider and the service provider is configured.
To send a NameIDMappingRequest message from the service provider, use the method of the com.sun.identity.saml2.profile.NameIDMapping.
public static NameIDMappingResponse initiateNameIDMappingRequest(
Map paramsMap) throws SAML2Exception;
And now that we are finished sweeping the floor, how about some dancing on the floor? Here's a home-made video to Paul Nicholas' number 7 hit from 1977, Heaven on the 7th Floor.
I know there are people out there who have been wondering where my blog entries have been for the last two and a half months - and to both of you I say: I've been assiduously (thanks for the word, Alan) working on two deployment books for release with Sun OpenSSO Enterprise 8.0. Here are links to the PDFs - test them out and let me know what you think.
But all that work has made me drowsy so I'm taking two weeks off now. In the meantime, enjoy As We Stumble Along featuring Robert Martin as Man in Chair and Beth Leavel as The Drowsy Chaperone. You gotta love a song that rhymes stumble with...parumble?
Between blog entries, I am writing the Sun Java System Federated Access Manager 8.0 Technical Overview. Aside from writing about new features, this book also includes updated material first written for Access Manager 7.1, the SAMLv2 Plugin for Federation Services and Federation Manager 7.0. Towards that lofty goal, I have finished a draft for the chapter entitled Implementing Federation. This chapter collects information regarding the federation protocol available in Federated Access Manager 8.0.
I've sent the chapter to internal Sun engineers for review but I also want to hear from the OpenSSO community. A PDF of this chapter is available for your perusal here. If you have any ideas on what might be missing, or comments on what is currently included please feel free to leave a comment or email me.
Since I'm gonna be strong when I read all these comments, here's Gene Pitney singing I'm Gonna Be Strong. This man has one of the best voices; I never tire of hearing the old records (yes, records) that I have of his.
Cyndi Lauper, one of the best female voices, covered I'm Gonna Be Strong when she was the lead singer of Blue Angel in 1980 (and then again on a solo album). Here's a clip of Cyndi singing the Barry Mann and Cynthia Weil classic with Blue Angel.
I also covered I'm Gonna Be Strong (a cappella, mind you) when I was performing songs and pithy comedy eons ago. I shall find that video tape and one day make this couplet a triplet. That should be scary!
This is a link to a PDF of the Federation, SAMLv2, and Web Services chapters of the FAM8 Developers Guide. This is a skeleton of what is going in the book. Let me know if you see something (or know of something) that I missed.
And here's another type of arms that belongs to someone with whom Elvis Presley wants to lie.
Loving Arms has been covered by many artists since it's original recording in the 60s. My favorite versions are Elvis's, the Dixie Chicks, and Ms. Millie Jackson. What's yours?