Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Authentication / Authorisation on Publish without needing sticky connections

Avatar

Level 3

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.

1 Accepted Solution

Avatar

Correct answer by
Employee

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

View solution in original post

5 Replies

Avatar

Correct answer by
Employee

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

Avatar

Employee

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.

Avatar

Level 3

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.

Avatar

Level 3

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.

Avatar

Level 3

Oh got it. Encapsulated token authentication & authorisation is available via the feature pack, right?