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(a)baseventure.com <craig(a)baseventure.com>*
On Sat, Nov 10, 2018 at 11:31 PM Dmitry Telegin <dt(a)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(a)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(a)baseventure.com
>
>
>
>
> > On Sat, Nov 10, 2018 at 1:49 PM Dmitry Telegin <dt(a)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(a)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(a)lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/keycloak-user
> >