ForgeRock Community Blog Syndicate

When you want to achieve Federation between different organizations, you often find yourself in a situation where the products used by the parties are different. Before we go any further I should make the terminology clear:
Identity Provider (IdP): The IdP holds all information about the user (for example in LDAP), and also it is the IdP’s job to authenticate the users, and decide on what kind of informations it shares about the users with other providers.
Service Provider (SP): The easiest way to think about the SP as an extra layer in front of the webapplication. The SP’s job is to authorize pagerequests, and if there is no authenticated session at the SP, initiate an authentication request to the IdP.

Today the goal is to achieve SSO between an OpenAM IdP and a Shibboleth SP with the simplest settings as possible.
This tutorial assumes that you already have a configured OpenAM instance running under idp.example.com.

Configure the IdP Log in to the admin console and on the Common Tasks pane click on the Create Hosted Identity Provider link. Select No for Do you have metadata for this provider Use http://idp.example.com:8080/openam as Name Select the default test Signing Key Use cot as the name of the New Circle of Trust Leave the Attribute mapping table empty Press the Configure then the Finish button Install and configure Shibboleth SP (on Ubuntu)

This tutorial was done with Ubuntu 11.04. If you have other OS/version it’s possible that the paths/steps will be different for you.

Install the Shibboleth SP Apache module: apt-get install libapache2-mod-shib2 Open the /etc/shibboleth/shibboleth2.xml configuration file using a text editor In SPConfig -> InProcess -> ISAPI -> change the Site tag to: In SPConfig -> RequestMapper -> RequestMap change the Host tag to: In SPConfig change the ApplicationDefaults opening tag to: In SPConfig -> ApplicationDefaults -> Sessions change the /Login SessionInitiator‘s opening tag to: In SPConfig -> ApplicationDefaults -> MetadataProvider create a MetadataProvider: In SPConfig -> ApplicationDefaults create an ApplicationOverride: Save the configuration file Make sure that the files referred in SPConfig -> ApplicationDefaults -> CredentialResolver actually exist, and if necessary, generate a self signed certificate (using this guide for example). Open http://idp.example.com:8080/openam/saml2/jsp/exportmetadata.jsp in your browser and save the XML as /etc/shibboleth/idp.xml (as configured in the MetadataProvider tag). (See this post for more information about exporting metadata.) Open the /etc/shibboleth/attribute-map.xml config file and add the following line: Prepare the Apache configuration

You need to configure Apache as well to make this setup work:

Make sure, that there is an sp.example.com VirtualHost in your Apache config If you want to use .htaccess you need to enable the AllowOverride AuthConfig in the VirtualHost config Create an index.php file in your docroot containing: Create a .htaccess file in your docroot containing: AuthType shibboleth ShibRequireSession On require shibboleth Enable the Apache Shibboleth module: a2enmod shib2 Restart Apache: /etc/init.d/apache2 restart Registering the SP at the IdP

If you’ve done everything right so far, then you can access your Shibboleth SP Metadata at http://sp.example.com/Shibboleth.sso/Metadata. In case the Metadata does not contain a certificate check the logs at /var/log/shibboleth/shibd.log, also please remember that whenever you change the Shibboleth config you need to restart the Shibboleth service:

/etc/init.d/shibd restart

NOTE: OPENAM-792 can cause you troubles while importing the metadata. Make sure you either have the fix for this issue, or you have removed the Extensions tag from the Metadata before uploading it.

If everything is OK with your Metadata open the OpenAM admin console and click on the Register Remote Service Provider link on the Common Tasks pane.

You can either upload the Metadata or provide the URL on the config page. Leave the attribute mapping empty Click on the Configure button Go to the Federation page then open the SP’s page in the Entity Providers table Go to the Assertion Processing tab In the Attribute Map list add the following value: urn:oasis:names:tc:SAML:2.0:attrname-format:uri| urn:oid:0.9.2342.19200300.100.1.1=uid Save the configuration and log out How to test

You just need to open a random URL under sp.example.com, and the htaccess config you created will make sure that the user is authenticated at the IdP. Opening such URLs should result in a redirect to the IdP presenting a login screen for you. After submitting the valid credentials you should be redirected back to the SP application to the originally requested URL. On the phpinfo page you should see the HTTP_UID server variable holding the user’s name.

In case you want to use the REMOTE_USER CGI variable in your applications, you can achieve that by modifying the Shibboleth configuration: in SPConfig -> ApplicationDefaults add HTTP_UID to the beginning of the REMOTE_USER attribute.

For many years, I’ve been working in collaboration with the Sun access management product team,  as it started working on the Directory Server Access Management Edition (DSAME) product that years later became Sun Access Manager and OpenSSO. And now that I’m at ForgeRock, I have the pleasure to keep working with some members of that team, on OpenAM, the continuation of the OpenSSO open source project.

My knowledge of the product is rather shallow as I’ve worked on several case studies or issues related to customers and LDAP directory servers, but I never had a chance to deploy a service for production use or even extensive testing.

So when I learnt that Packt Publishing was releasing a book on “OpenAM”, writen by Indira Thangasamy, an ex-colleague of mine and manager of the Quality Assurance team, I asked if I could get a copy for review, which Packt kindly agreed to.

I haven’t finished the book yet, as it’s over 250 pages of content, covering all aspects of the OpenAM software, from its history, its components and services, to its integration with Google Apps or SalesForce… But from what I’ve read (about 2/3 of the book), I can say that the book is easy to read and well organized. It helps a beginner to grasp the concepts and starts using the product, thanks to the detailed explanations and diagrams. As the chapters advance and dive into specific technical areas, Indira uses real-world examples and simple code or commands, followed by detailed description to illustrate what OpenAM does or does not, giving a comprehensive picture of the fully featured product.

Some of the features of OpenAM are not covered in the book, like Federation or the most recent Entitlement Services or Secure Token Services. I hope they will be covered in a revised edition or may be another book, as these features are becoming more used and important to enterprise security and access management.

In summary, if you’re about to, or have just started to engage on a project with OpenAM, this book will help you understand the technology and ease your ramping up. But even for the more experienced users of OpenAM, the book contains full of details, tips and example that will save you time and make you more efficient.

You can find the book on Pack-Publishing web site or Amazon.

Filed under: Identity Tagged: access-management, authentication, authorization, book, federation, ForgeRock, identity, openam, opensource, opensso, review, security, sun

Sometimes it’s useful to have federation metadata online available. In these cases, here are few URLs for accessing SP/IdP metadata on your OpenAM server.
If you want to access your IdP metadata, open the following URL:

https:///openam/saml2/jsp/exportmetadata.jsp?entityid= https://:443/&realm=/realmname

If you need to retrieve your SP metadata, then use the following URL:

https:///openam/saml2/jsp/exportmetadata.jsp?spentityid= https://:443/&realm=/realmname

And that’s it. The IdP-uri is what you have setted when you’ve created the hosted IdP in OpenAM console, and the SP-uri depends on your SP vendor, for example in case of Shibboleth the SP-uri is /shibboleth.

Although OpenAM is supplied with a default keystore, it’s recommended to create your own keystore with an own signing key. This keystore is used by the federation and WSS agents, so if you already use those, make sure, you’re not using them with the default ‘test’ private key.
So, if you want to change your default keystore, then you need to do the following:

Generate a new key and keystore (skip if you already have one): keytool -genkeypair -alias mykey -keyalg RSA -keysize 1024 -validity 365 -storetype JKS -keystore keystore.jks

This will ask you some trivial questions, you just need to answer them.

Now you need to encrypt your passwords (keystore and private key) with SSOAdm, to be able to use them with OpenAM: openam/bin/ampassword -e .keypass # for private key openam/bin/ampassword -e .storepass # for keystore

Override the files with the ampassword output, so they would only contain the encrypted password. Move the new files (keystore.jks, .storepass, .keypass) to ~/openam/openam folder and override the previous ones. Restart OpenAM If you already had a configured Federation, then go to Federation -> in Entity Providers list choose the IDP -> Signing and Encryption -> and change the signing key alias to the new alias.

Note: if you change the signing key, you need to make sure, that all of the SP’s will accept the new sign too!

Sadly OpenAM Snapshot 9 is shipped with a small Federation bug, which shows up in the following form:

When a user came from an SP, the login form is showed up, but when he tries to submit the form, the page is simply reloaded and the GET parameters are gone, so when he tries to login again, then the login works, but the browser is redirected to the default success URL and not the original SP-protected page. Also if you check your webcontainer log files, then you should see something like this:

[WARNING] Could not load ViewBean class "com.sun.identity.authentication.UI. RedirectViewBean" via Class.forName(); attempting to use current thread's context class loader

The problem is that the browser was redirected to /opensso/UI/Redirect instead of /opensso/UI/SSORedirect. This issue is known (OPENAM-3), and it is already resolved in OpenAM trunk, so if you need a patch for this, then here it is, apply it, and federation will work as good as in the old days.

A recent request on the mailing list caught my attention as I’ve been working on this just recently. In OpenAM, every log entry has a ContextID but which context is this really? Unfortunately, the answer is not too simple, and tracing activity over the course of a federated authentication, for example, is not trivial.

I’ll take a typical scenario where OpenAM is an IDP in a SAML2 federation, with focus on the following log events:

SP sends AuthnRequest to OpenAM IDP Module based authentication using LDAP module Login success log message (Post processing log message) ArtifactResolve and Response Single logout

As stated above, each log entry has a ContextID which is the OpenAM session ID of the user who performs the log operation. Easy, right? Well, no. Taking the first event here, an SP who sends an AuthnRequest to the IDP (OpenAM), then the incoming AuthnRequest is logged to the SAML2 log but since we don’t have a user in the picture (no response has been sent to the user yet) then this is logged by an administrative user. This means that for #1, the ContextID is actually a session ID that may also be shared by other log operations for different users. The AuthnRequest xml contains a MessageID which can be used later for tracing purposes.

The next message in this scenario, where the user authenticates using the LDAP module, could be success or failure – in any case, the user at this point is in dialog with OpenAM and has received an AMAuth cookie which represents their session. So for #2 the ContextID is the session ID of the user whilst they are authenticating. As we will see, the session is replaced with an authenticated session shortly afterwards.

By the time the user has met the authentication requirements in the module or chain/service, then a big change happens: in the LoginState class the temporary session used whilst authenticating is destroyed and a new authenticated session created containing user attributes. the iPlanetDirectoryPro cookie is set with the session ID of this new session and the AMAuth cookie is removed. After this point (#3 and #4) all the user operations are logged with a ContextID that is the session ID of their authenticated session.

One exception to this is in a SAML2 Artifact profile, where the SP has received a token and calls a web service to resolve it, the ArtifactResolve message. This request is direct from SP to IDP and not via the user’s browser, so OpenAM has no immediate access to the user’s session cookie. The receipt of the ArtifactResolve message is therefore logged as an administrative user, similar to #1 but not necessarily the same, and not unique to the user involved. So the ContextID in #5 is fairly meaningless. However, the SAML2 messages are traceable through the MessageID and InResponseTo attributes. Also, in the ArtifactResponse message (the SAML Assertion), there is a session ID which is separate from the OpenAM session ID, and that can be traced to #6 Single logout.

–

The above behaviour is partly due to the information available at each time, but there are definitely ways of improving traceability of log messages. This is on the roadmap here at ForgeRock; watch this space!

(PS: This post is written from memory so there may be some misplaced details. I’ll try to review it with my notes in front of me next week)