The Oracle IAM suite requires starting quite a few admin and managed server instances.
During development you often want to watch the server output to diagnose errors.
Here is a sample script to launch an Admin server and the associated managed servers. The output for each server will go to a new gnome-terminal window.
You might want to create a master shell script that invokes this script for each of your instances.
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:
<Site id="1" name="sp.example.com"/>
- In SPConfig -> RequestMapper -> RequestMap change the Host tag to:
<Host name="sp.example.com" applicationId="sp.example.com" />
- In SPConfig change the ApplicationDefaults opening tag to:
<ApplicationDefaults id="default" policyId="default"
REMOTE_USER="eppn persistent-id targeted-id"
- In SPConfig -> ApplicationDefaults -> Sessions change the /Login SessionInitiator‘s opening tag to:
<SessionInitiator type="Chaining" Location="/Login"
isDefault="true" id="Intranet" relayState="cookie"
- In SPConfig -> ApplicationDefaults -> MetadataProvider create a MetadataProvider:
<MetadataProvider type="XML" file="idp.xml" />
- 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:
<Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="HTTP_UID"/>
Prepare the Apache configuration
You need to configure Apache as well to make this setup work:
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:
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.
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.
The ForgeRock is a rolling stone at the moment and gathering no moss. Here are some of the things we have been up to recently:
As it happens, our Rock is at the top of a big hill and we are still picking up speed
Names come in all forms and sizes; official and informal, first middle and last, identifiers and labels. And here is a new type of the name: the ForgeRock name.
As Joe Brockmeier discussed in a blog entry last year, Open Source does not normally say anything about the trademarks that may apply to the software. The current situation in Sun-Oracle may leave a number of Open Source projects out in the cold – and when crunch time comes (is it here already?) then this may be a hot issue.
As Oracle recently removed all open downloads from opensso.org, ForgeRock are the new home of binary downloads for the OpenSSO community, providing essentially the same compiled code as before. Except for the name.
So – OpenAM is the new OpenSSO. Remember the name next time you need a build
Everything starts somewhere, and this blog is starting for a reason. We at ForgeRock have recently launched our business and have a lot to say – this blog is one of those ways
So I can start off by saying that the purchase of Sun by Oracle took a long time but was finally completed on January 27th. As you will see from www.forgerock.com, ForgeRock has it’s roots in the software side of Sun, with almost all our employees having a background from Sun. Naturally we have been interested to see how the takeover would play out, especially with regards to Sun’s open source strategy. Oracle has made several statements about the direction they will be taking including these webcasts.
One of open source products we are particularly involved in is OpenSSO – a fully-featured, enterprise-class product for authentication, authorization, federation and much more. Oracle has said that OpenSSO will continue as an open source project but that Oracle Access Manager will be their strategic product for web single sign-on, and Oracle Federated Identity Manager for federated single sign-on.
What does the “strategic” product choice mean in practice? Nishant Kaushik (architect for Identity Management products at Oracle) in his blog answers like this:
“Strategic” means that this is the product that we will be innovating and developing new features for.
So according to this Oracle will not be innovating and developing new features for OpenSSO, but still hosting the open source project. This can also be seen on the employee side of Oracle where key players from the OpenSSO team are apparently either no longer working there or have been transferred to other teams.
What is the next step for OpenSSO then?