[keycloak-user] Adding attributes during login

Craig Setera craig at baseventure.com
Sun Nov 11 07:56:44 EST 2018


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 <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