I am looking for a solution for integrating with our IDP (ForgeRock) where authentication would not require any server side persistence of a token (e.g, using JWT). That way I wouldn't need to worry about sticky connections.
Is that possible in AEM. I've not tried out all possibilities, but looks like all implementations recommended by AEM would involve synching some user data from IDP to AEM and then relying on sticky connections to ensure the visitor gets redirected to the publish instance with the user data on.
A side question is, can I overwrite the authorisation step used in CUG as I want to use CUGs but I don't want the user data on AEM. Such that I can verify the group permissions without the user actually being part of that group.
Another side question, can I configure multiple SAML configurations on the publish environment. E.g, diff one for siteA compared to siteB (because I want the redirect URL to be different).
Thanks in advance.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
Encapsulated token-based authentication and support for multiple SAML IDPs are available for AEM 6.0 as feature packs. Please get in touch with Daycare. You will need to persist some user data and ensure that this user data is available on on publish instances.
Regards,
Justin
Views
Replies
Total Likes
Hi,
Encapsulated token-based authentication and support for multiple SAML IDPs are available for AEM 6.0 as feature packs. Please get in touch with Daycare. You will need to persist some user data and ensure that this user data is available on on publish instances.
Regards,
Justin
Views
Replies
Total Likes
Yes, although it is non-trivial and something you should work with Adobe Consulting or a specialized partner on. It would be better to pass this policy data in the SAML assertion mapped to group/role names in AEM. If you use encapsulated tokens, you do not need sticky connections.
Views
Replies
Total Likes
Thanks Justin.
Is it possible to overwrite CUG functionality with our own service where we get an authenticated user's policy or entitlement from a 3rd party system (e.g., a group name) and then check if it matches the CUG requirements on a resource. I don't want to store User data in the JCR as then I'd need to enable sticky connections which kind of breaks the whole redundancy model we've got baked in.
Views
Replies
Total Likes
Thanks Justin. With 3rd party authentication & SSO more and more being adopted by large corporations, I assume the ability to define protected content per policy without having users / groups in AEM will be something that AEM will be delivering some time in the future???
What do you mean with encapsulated tokens? Is there some documentation somewhere on Adobe's website. My initial question was to do authentication & authorisation withing sticky connections (and ideally without user data persistence), so looks like the answer is there.
Views
Replies
Total Likes
Oh got it. Encapsulated token authentication & authorisation is available via the feature pack, right?
Views
Replies
Total Likes
Views
Likes
Replies