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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user