-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 11.0.2, 12.0.0, 13.0.0
-
Component/s: SAML
-
Labels:
When having a SP in a subrealm with 11.0.2, some functionality is lost. Through testing I confirmed that auto-federation is an issue as well as creating a user account locally.
To reproduce:
Create a SP in a sub-realm
Enable Auto-Federation
(I used NameID Format transient and Dynamic profile, but there are issues in other configurations too)
The issue is caused by the fix for OPENAM-474, more specifically in FMSessionProvider.java:
ac.login(AuthContext.IndexType.MODULE_INSTANCE, "Federation", null, null, request, response);
At some point during the SAML process, the realm coming from the authentication context is compared (and must match) the realm coming from the query string. However the piece of code above means that the organization parameter for the query string returns null; instead, the code will then use DNS Alias to determine the realm, which ends up being the top realm; as it does not match, authentication fails.
Workaround:
The following workaround worked for me:
- Create an alias: alias.example.com for my subrealm /test
- Modify the Assertion Consumer Service accordingly: for each needed entry, e.g.: http://alias.example.com:8080/openam/Consumer/metaAlias/test/sp
- Update the IDP with the new SP_Metadata/ExtendedMetadata
- Restart OpenAM
Make sure alias.example.com can be accessed from outside
Access as usual: http://sp.example.com:8080/openam/saml2/jsp/spSSOInit.jsp?idpEntityID=idp&metaAlias=/test/sp
- relates to
-
OPENAM-474 Dynamic User Creation not populating all available attributes onto newly created user
-
- Closed
-