Authentication / Authorisation on Publish without needing sticky connections | Community
Skip to main content
K
Katrien1
Level 3
October 16, 2015
Solved

Authentication / Authorisation on Publish without needing sticky connections

  • October 16, 2015
  • 5 replies
  • 2288 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by JustinEd3

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

5 replies

J
Adobe Employee
JustinEd3Adobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

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

J
Adobe Employee
JustinEd3Adobe Employee
Adobe Employee
October 16, 2015

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.

K
Katrien1Author
Level 3
October 16, 2015

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.

K
Katrien1Author
Level 3
October 16, 2015

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.

K
Katrien1Author
Level 3
October 16, 2015

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

Terms & ConditionsAccessibility statement

Loading footer...