[keycloak-user] Adding attributes during login
Dmitry Telegin
dt at acutus.pro
Tue Nov 13 17:54:51 EST 2018
Hello Craig,
Unfortunately I didn't have time for a full PoC, but here are some ideas that might be helpful.
On Sun, 2018-11-11 at 19:12 -0600, Craig Setera wrote:
> We want to "brand" (color and logo) the user-facing parts of the application based on the partner code. I think that means:
>
> - Login theme
I think we have covered this in the previous thread (dynamically branded login). In case your auth flow contains additional steps like optional OTP, and you want to brand them too, you can reuse already populated user session notes.
Use the same technique (extend FreeMarkerLoginFormsProvider and override createCommonAttributes) to obtain partner code from the user session (via authenticationSession field) and push it to Freemarker context via template attributes.
> - Email theme
Similarly, extend FreeMarkerEmailTemplateProvider and override processTemplate() to pass your partner code from authenticationSession to the template attributes.
> - Account theme
This one will be a bit more complex, since FreeMarkerAccountProvider doesn't have authenticationSession field. However, you can use org.keycloak.services.managers.AuthenticationSessionManager to obtain current user session. As the final step, again override processTemplate().
Good luck,
Dmitry
>
> Craig
>
> =================================
> Craig Setera
> Chief Technology Officer
>
>
>
>
> > On Sun, Nov 11, 2018 at 5:47 PM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi Craig, you're welcome :)
> >
> > As for "theme engine", in fact there are five types thereof in Keycloak:
> > - Welcome theme
> > - Login theme
> > - Admin console theme
> > - Email theme
> > - Account theme
> >
> > Which one is most relevant to your problem? And, more generally, what are you trying to achieve?
> >
> > Cheers,
> > Dmitry
> >
> > On Sun, 2018-11-11 at 06:56 -0600, Craig Setera wrote:
> > > Wow! This is great. Thanks so much. I will have to give this a try this week and see if I can make it work. You are correct that this is also the code that we want to use to drive our branding. Are the session notes or token claims available to the theme engine?
> > >
> > > =================================
> > > Craig Setera
> > > Chief Technology Officer
> > > 415-324-5861
> > > craig at baseventure.com
> > >
> > >
> > >
> > >
> > > > > > On Sat, Nov 10, 2018 at 11:31 PM Dmitry Telegin <dt at acutus.pro> wrote:
> > > > Hello Craig,
> > > >
> > > > Thanks for the explanation, it's pretty clear now. I guess that "partner code" is the same parameter you use to dynamically brand your login themes, right?
> > > >
> > > > First, you need to extract it from your request parameters. In Keycloak, you can do this with a script authenticator. Things are a bit complicated by the fact that the initial incoming link (protocol/openid-connect/auth) does a POST to another endpoint (login-actions/authenticate), and the script authenticator is able introspect only the second request. Query parameters do not survive POST, but still can be found in the Referer header; therefore, you need to fish them out of there. (NB this will only work unless sending this header is disabled in the browser by a paranoid user :)
> > > >
> > > > Create it as the last authenticator in the flow and make it "required". It's up to you how to handle the case where there is no "foo" parameter in the initial link.
> > > >
> > > > ===================================================
> > > > function authenticate(context) {
> > > >
> > > > var username = user ? user.username : "anonymous";
> > > >
> > > > var uri = new java.net.URI(httpRequest.httpHeaders.getHeaderString("Referer"));
> > > > LOG.info(uri);
> > > > var uriInfo = new org.jboss.resteasy.spi.ResteasyUriInfo(uri);
> > > > var _foo = uriInfo.queryParameters['foo'];
> > > > if (_foo !== null ){
> > > > var foo = _foo[0]; // uriInfo.queryParameters is a multivalued map
> > > > LOG.info(script.name + ": " + username + " foo=" + foo);
> > > > authenticationSession.setUserSessionNote("foo", foo);
> > > > }
> > > >
> > > > context.success();
> > > >
> > > > }
> > > > ===================================================
> > > >
> > > > (Quick remark on terminology: in Keycloak's terms, "attributes" are persistent pieces of data attached to a user, group or realm; you can find them in the corresponding GUI tabs. Transient data is called "[session] notes".)
> > > >
> > > > Next, you will need to propagate it to the tokens. Again, JavaScript to the rescue, this time in the form of script mapper (client -> Mappers):
> > > >
> > > > ===================================================
> > > > var foo = userSession.notes["foo"];
> > > >
> > > > if (foo !== null) {
> > > > token.setOtherClaims("foo", foo);
> > > > }
> > > > ===================================================
> > > >
> > > > And voilà, your query parameter is now in the tokens :)
> > > >
> > > > Good luck!
> > > > Dmitry Telegin
> > > > CTO, Acutus s.r.o.
> > > > Keycloak Consulting and Training
> > > >
> > > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > > > +42 (022) 888-30-71
> > > > E-mail: info at acutus.pro
> > > >
> > > > On Sat, 2018-11-10 at 14:01 -0600, Craig Setera wrote:
> > > > > Dmitry,
> > > > >
> > > > > Thanks for responding and sorry for not being more clear.
> > > > >
> > > > > The circumstance is that a username may be associated with multiple different companies in our system. However, if the user is logging in from a link that originated from company X, we want to limit what they are authorized to view based on the incoming link to preserve the view of separate tenancy. So, the partner code is provided (hidden) for each login. The hope would be that it would be part of the initial login URL as a query parameter, be captured in Keycloak and then made available throughout the "session" associated with the access/refresh tokens.
> > > > >
> > > > > Thanks!
> > > > > Craig
> > > > >
> > > > >
> > > > > =================================
> > > > > Craig Setera
> > > > > Chief Technology Officer
> > > > > 415-324-5861
> > > > > craig at baseventure.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > > On Sat, Nov 10, 2018 at 1:49 PM Dmitry Telegin <dt at acutus.pro> wrote:
> > > > > > Hell Craig,
> > > > > >
> > > > > > Do you mean the user should enter a "partner code" along with login+password? (either as a 3rd field or in a separate screen)
> > > > > > Or only once during registration / upon the first login?
> > > > > >
> > > > > > Cheers,
> > > > > > Dmitry Telegin
> > > > > > CTO, Acutus s.r.o.
> > > > > > Keycloak Consulting and Training
> > > > > >
> > > > > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > > > > > +42 (022) 888-30-71
> > > > > > > > > > > > E-mail: info at acutus.pro
> > > > > >
> > > > > > On Sat, 2018-11-10 at 09:00 -0600, Craig Setera wrote:
> > > > > > > We have an attribute we use to allow customers to to "scope" or "namespace"
> > > > > > > a users interaction with our system (a "partner code" that is known to our
> > > > > > > system). In our previous proprietary Java session-based security system,
> > > > > > > this value was stored in the Java session at the time of login and used by
> > > > > > > the authorization engine to further restrict what the user was allowed to
> > > > > > > see.
> > > > > > >
> > > > > > > As we transition to using Keycloak for authentication, I'm wondering if
> > > > > > > there is a way to use Keycloak to manage this partner code during a login
> > > > > > > session? Some way to send the value during the Keycloak login sequence and
> > > > > > > then later retrieve it based on the access token?
> > > > > > >
> > > > > > > Thanks for any insights.
> > > > > > > Craig
> > > > > > >
> > > > > > > =================================
> > > > > > > *Craig Setera*
> > > > > > >
> > > > > > > *Chief Technology Officer*
> > > > > > > _______________________________________________
> > > > > > > keycloak-user mailing list
> > > > > > > keycloak-user at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > > >
> > > >
> >
More information about the keycloak-user
mailing list