June 23, 2015 at 2:24 am #4496PareshParticipant
We want to support SSO from OpenAM to Office365. In our test environment, we are using the embedded OpenDJ in OpenAM to manage users, but our production system talks to Corporate AD for users/groups.
By referring to this wiki document [https://wikis.forgerock.org/confluence/display/openam/Microsoft+Office+365+Integration] we were able to successfully get SSO working from OpenAM to Office365 in test setup. Now we are planning how this would work in production and one of the issues is that in test we had updated the user entry to add “sun-fm-saml2-nameid-info” & “sun-fm-saml2-nameid-infokey” attributes. These attributes are used for Persistent NameID format with Office365.
However, we cannot pollute our Corporate AD user schema by adding these attributes and also OpenAM is not allowed to perform any writes to AD. Hence, we wanted to know if there is some other way to achieve Federation to Office365 without requiring any updates to AD user.
The Office365 SAML metadata [https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml] indicates that it accepts following NameID formats:
One approach we are considering is that we use the NameID format as emailAddress and set the ImmutableId in Azure AD as the user’s email address. Also, we configure OpenAM to send emailAddress as the NameID format. Has anyone tried such a setup with Office365? Any pointer or suggestions are most welcome.
Paresh.July 2, 2015 at 12:55 am #4628
OPENAM-3470 is probably something you’ll want to apply to improve the behavior around NameID value persistence.July 8, 2015 at 1:44 am #4657PareshParticipant
I had a look at the details in OPENAM-3470, but my understanding is that it resolves an issue with persisting nameid format values other than “Persistent” nameid format. Hence, it does not seem relevant with Office365 which only supports Persistent NameID format only.
Does OpenAM support any means to specify an existing user attribute which should be used for Persistent NameID format? For example – in my case we want to use sAMAccountName attribute from the user entry as the NameID format value. Note we ensure that sAMAccountName value is set on Office365 end as the ImmutableID value for the user (one could use OpenIDM for this). Hence, I tried to set “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent=sAMAccountName” in the “NameID Value Map” in IDP configuration in OpenAM, but encountered an error “Creation of NameID is not allowed per AuthnRequest.” during SAML SSO.
Note we cannot add the attributes used by OpenAM for Persistent NameID format support (sun-fm-saml2-nameid-info, sun-fm-saml2-nameid-infokey) to our corporate AD, as it is read-only for OpenAM. Is there someway to support Persistent NameID format with OpenAM without leveraging these specific attributes?
Also, on a side note I had a look at the default IDP account mapper implementation [com.sun.identity.saml2.plugins.DefaultIDPAccountMapper] and it seemed like it should have handled Persistent NameID Format as samAccountName, but the error returned by OpenAM indicates otherwise. Probably Persistent NameID format is handled differently?
Any pointers or suggestions will be helpful.
Paresh.September 14, 2015 at 9:41 am #5448
We have exactly the same question at this point. We already store a global unique ID for every user in our LDAP and want to use that one for the persistent response.
Did you succeeded into doing this?September 14, 2015 at 4:40 pm #5455
@Paresh in your initial post you’ve suggested that Office365 supports other NameID-Formats as well, if that is really the case, then you should be able to use something else than persistent NameID-Format and that should also prevent the need from persisting the NameID values by OpenAM.
The SAML core spec is quite clear that if persistent NameID-Format is being used, then the NameID value must be an opaque identifier:
Persistent name identifiers
generated by identity providers MUST be constructed using pseudo-random values that have no
discernible correspondence with the subject’s actual identifier (for example, username).
Persistent NameID-Format will always require the persistence of the NameID values, and as such it will always require write access to the underlying data store (the attribute name can be changed from the default, but that’s about it).
@wniehof if you already have an identifier then probably you shouldn’t use persistent NameID-Format, urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified format may be more appropriate.September 14, 2015 at 8:04 pm #5484
Unfortunately, although the metadata of Office365 suggested otherwise, it seems only persistent nameid is supported. I haven’t found a way (or any documentation) that you can change this.
Bit Microsoft does state that the NameID value should be the same as the ImmutableID on the user that has already been provisioned to Microsoft. Therefor it’s not very convenient when you let the IDP make up such an ID, but instead use and ID that already exists.September 15, 2015 at 2:43 pm #5494
OpenAM allows to set up persistent federation links if the necessary mappings are already known, the following document should tell you exactly how to do that:
Note: the do-bulk-federation command will set the sun-fm-saml2-nameid-info and sun-fm-saml2-nameid-infokey attributes on the user entries, so write access to the user data store is still necessary.September 16, 2015 at 9:43 am #5502
Thanks again for your help.
This is interesting but not exactly what we need. Because this requires us to run an SSOADM script after every newly created user.
I also already created a support ticket for this and Nathalie is helping me. She already told me the reaction of OpenAM to a persistent nameid format request is something that sits pretty deep in the core of OpenAM.
So we could use our own values, but still OpenAM needs to write some values in the sun-fm-saml2-nameid-info and sun-fm-saml2-nameid-infokey attributes (and then we just overwrite them later in the process with our own values)September 16, 2015 at 10:28 am #5504
You could just as well set up your provisioning solution to automatically save the persistent NameID (deduced from ImmutableID) in the sun-fm-saml2-nameid-info* attributes, that should resolve the problem you are having.
Alternatively you could write a custom IDPAccountMapper that handles persistent NameID-Format slightly differently than the default implementation. The code that persists and retrieves the NameID value from is independent from the account mapper, and in case of using persistent NameID they will be *always* done.
You must be logged in to reply to this topic.