Expand my Community achievements bar.

SOLVED

Override login-token path in AEM

Avatar

Level 1

Hi,

I have been working on a requirement where an AEM instance should support multiple SAML connections for different parts of same site. Since, these different parts of site are mutually exclusive, setting up SAML configurations is not a problem and works fine for authenticating a user.

Following is the structure of the site:

  • /content/site/parta - protected by IDP SAMLA
  • /content/site/partb - protected by IDP SAMLB

However, when authenticated user navigates from parta to partb, user is still considered authenticated as AEM is validating login-token and since it finds an valid login-token, it treats the user as authenticated even though its different saml path at which user has authenticated. We are currently using an awkward workaround by creating a cookie to track where the user has logged in from and when they try to navigate to other part of site, I am forcing user to go thru logout. I can also use CUG by assigning users to different groups when they authenticate with different IDPs and use permission based access. But both of them dont goto IDP login without forcing user to logout at AEM.

I have tried to change the login-token path to say AEM has authenticated on parta and so if user access partb, they will graciously go through SAMLB login flow instead of having to go thru AEM logout.  For this, I tried changing login-token path by implementing AuthenticationInfoPostProcessor and also using sling filter. However, changing the path is creating a new cookie instead of updating it as both events are happening after POST /saml_login call from IDP.

Any suggestions as how this can be solved?

Thanks!!

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Ok, I understand. In that case the IDP B does not authenticate any more, but only authorizes an already authenticated user to perform some more actions/see more data.

The simpliest idea to solve it with AEM features is probably if the IDP B just adds some more groups to the user, so the user can now see the additional content too. And in case of logout remove these additional groups from the user again. Or if you could hide the additional login into some impersonation-like feature.

My idea is that you model this requirement with permissions. Because permission are already in place to model the visibility of pages, and you just need to add the permissions to the user, or combine these additional permissions into a group and make the user a member of it. This only leaves the question open how to get this together with SAML.

View solution in original post

3 Replies

Avatar

Employee Advisor

Hi,

If you use different IDPs for a site, why do you use the same user for it? Or in other words. If you authenticate an AEM user max against IDP A, it should not possible to authenticate max also against IDP B; each IDP should have their own set of users.  Because then you can work with permissions to separate the areas from each other.

(I don't see any reason why a user max in the IDP A should have the same principal as the user max in the IDP B. Because then you don't have a single source of truth anymore...)

Jörg

Avatar

Level 1

Hello Jörg Hoh

We have different IDPs for internal and external users for same site. However, the part of site which needs authentication is mutually exclusive for both. So assume Max an internal user wants to access part of site meant for external users which requires additional attributes that are usually provided by IDP and has tight integration with ERP, i want user Max to go thru login flow more graciously than forcing the user to go thru logging out first. I thought modifying login-token path would be obvious way to do it.

Hope you see where i am coming from.

Thanks!!

Avatar

Correct answer by
Employee Advisor

Ok, I understand. In that case the IDP B does not authenticate any more, but only authorizes an already authenticated user to perform some more actions/see more data.

The simpliest idea to solve it with AEM features is probably if the IDP B just adds some more groups to the user, so the user can now see the additional content too. And in case of logout remove these additional groups from the user again. Or if you could hide the additional login into some impersonation-like feature.

My idea is that you model this requirement with permissions. Because permission are already in place to model the visibility of pages, and you just need to add the permissions to the user, or combine these additional permissions into a group and make the user a member of it. This only leaves the question open how to get this together with SAML.