Tagged: OpenAM SAML federation
December 19, 2016 at 12:32 pm #14887nikolaosinlightParticipant
I am setting up on an IDP Proxy and an SP (both OpenAM 13.5) and would like to NOT have user accounts created on the IDP Proxy. Essentially I would like to flow the SAMLv2 assertion/attributes through the IDP Proxy to the SP were the user profile gets dynamically created.
1. I plan on setting IDP Proxy “User Profile” to Ignored. Should I enable auto federation at IDP of IDP Proxy?
2. I plan on setting SP “User Profile” to Dynamic and enabling auto federation on the SP.
Am I missing anything above? Is the Open 13.5 OOB behaviour sufficient to accomplish this? Do I need to customize AccountMappers and/or AttributeMappers.
–NikolaosDecember 20, 2016 at 12:10 pm #14934Peter MajorModerator
1) Auto federation can be only enabled on the SP side… Enabling it is probably a good idea though.
2) keep in mind that OpenAM is NOT an identity management tool… AM will not update the user entry in your data stores based on newer data from more recent assertions.December 20, 2016 at 6:13 pm #14981nikolaosinlightParticipant
Thank You for the response. Indeed I am aware of the fact that User Profile attributes are not updated – have seen this with Dynamic Profiles flowed from AD. Would be cool if OpenAM had the OOB ability but that is another RFE topic :-)
I get that auto federation works on the SP but does it not work as well for the SP configuration of an IDP Proxy? i.e. an IDP Proxy has both an IDP and a SP side – I am looking at whether auto federation can be employed to federate user from IDP to IDP Proxy.
A side question: In the case of an IDP Proxy are both the IDP *and* SP Account Mappers involved or is only 1 of them involved and if so which?
Lastly, I find it a little frustrating that there are XML attributes that are available in say IDP but really act like an override for SP and others for say IDP but actually act on the IDP. Case in point autofederate attributes exists in both IDP and SP extended metadata yet I don’t think I read anything about it being specifically for SP. Have seen *=* being just for SP though but perhaps this can be improved in docs or you can direct me to what I am missing :-)
Thank You Kindly,
–NikolaosDecember 21, 2016 at 11:10 am #14997Peter MajorModerator
1) auto federation will work just fine on the SP side of the IdP proxy
2) both the SP and the IdP account mappers will be invoked as part of the IdP proxy’s SAML processing.
3) IdP settings do not override SP settings, actually it’s exactly the other way around: the IdP settings serve as a default, and you can change the configuration for an individual SP if you’d like. (In some cases actually we are missing more SP specific settings)
4) sadly only the hosted SP supports *=* attribute mapping, the IdP has no real knowledge of the assertion that just has been received from the remote IdP, as such you’ll need to set up specific attribute mapping in the IdP configuration.
You must be logged in to reply to this topic.