Hello Neelima,
I think this can be solved with a custom authenticator, as Stian suggested.
To make it appear unconditionally, regardless of the authentication status, configure your
flow like this:
https://i.imgur.com/TwslFME.png
The idea is to move the actual authentication stuff into a subflow and make it
"alternative", while your authenticator should be "required". Each
time Keycloak auth endpoint is requested, the authenticator will be invoked even if the
user is already logged in.
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 Tue, 2018-10-23 at 18:03 +0000, Karipineni, Neelima,M.D. wrote:
I believe that’s essentially what the action-token-authenticator
quickstart does. I tested this out and it only shows the additional step if the user has
not previously authenticated. If the user has an existing session, it forwards to an error
page that says “You are already logged in”. I did make it required and not optional
though, since my understanding is that only one optional authenticator needs to
successfully run.
We need something that displays the additional consent step every time there is a new
auth code request with the specified scope, regardless of whether the user has previously
authenticated. It’s also preferable that the user has successfully authenticated prior to
showing the additional consent page, because there may be confidential data on the consent
page (ie, a search widget for a patient identifier).
> From: Stian Thorgersen <sthorger(a)redhat.com>
> > Reply-To: "stian(a)redhat.com" <stian(a)redhat.com>
Date: Tuesday, October 23, 2018 at 1:51 PM
> To: "Karipineni, Neelima,M.D." <NKARIPINENI(a)BWH.HARVARD.EDU>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] OIDC protocol extension
External Email - Use Caution
I wouldn't to a custom login protocol as that would be very hard to maintain.
We've actually ended up refactoring the branch you point to into not using a login
protocol.
Why not use an optional authenticator for this purpose? It can check the scope and only
display the additional consent step if the certain auth request scope is there. It can
then add a note to the user session which you can map into the token with a protocol
mapper.
> On Tue, 23 Oct 2018 at 18:29, Karipineni, Neelima,M.D.
<NKARIPINENI@bwh.harvard.edu<mailto:NKARIPINENI@bwh.harvard.edu>> wrote:
We have a use case where we’re trying to implement an OAuth2 profile which requires an
extra claim on the access token when a certain auth request scope is used.
The expected behavior is that when a certain scope is present in the auth endpoint
request then during the Authorization flow the user is shown an extra screen where they
input an identifier which ultimately is included as a claim in the access token. Details
are at
http://docs.smarthealthit.org/authorization/ (Standalone launch sequence) for
reference.
Any suggestions on how to accomplish this in keycloak? I considered using an ActionToken
like in the quickstarts external action token example, but the additional execution needs
to happen even when the user has previously authenticated. It’s like an additional consent
step after user and client authentication rather than an additional authentication step.
My current thought is to implement a custom LoginProtocol that wraps OIDCLoginProtocol,
as shown in
https://github.com/keycloak/keycloak/tree/openshift-integration/services/...,
and have an additional redirect in the authenticated method that functions similarly to
the external action token example. The callback endpoint would persist the extra claim
against the client session until the access token is requested.
I’m not sure it’s possible to extend the OIDC protocol within a new protocol.
Preliminarily after installing a shell wrapper protocol, it’s missing the OIDC
configuration properties and mappers in the admin console. Is something like this possible
without copying/recreating large chunks of the OIDC code? If not, any suggestions on
alternative ways to accomplish this?
As an additional wrench, we’re still on v3.3.0 and upgrade is not on the schedule as of
now.
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
_______________________________________________
keycloak-user mailing list
> keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user