It would work regardless - whatever mechanism would be used in realm
resource, it can just the same be used in action token handler.
If authentication session would not be distributed, the token would be
prepared to contain identification of the target node/DC but not
contain mapping to any authentication session at all. The action token
handler would use information from the token to send an event that
would reach the right node/DC.
On Wed, Jul 12, 2017 at 3:08 PM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
The trick is that it should work even when authentication session is
not
distributed. The authentication session cache could be local only and in
that case there needs to be a way to send an event from whatever node/DC
handles the callback to the node/DC that contains the authentication
session.
On 12 July 2017 at 14:37, Hynek Mlnarik <hmlnarik(a)redhat.com> wrote:
>
> That should not change the code in any way as that is matter of
> authentication session distribution within the cluster/cross DC rather
> than of action tokens. AFAIK Marek is currently working on that.
>
> On Wed, Jul 12, 2017 at 2:30 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
> >
> >
> > On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik(a)redhat.com> wrote:
> >>
> >> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen
> >> <sthorger(a)redhat.com>
> >> wrote:
> >> > Action tokens may work in some situations, but may not always work.
> >> > If
> >> > there
> >> > is a specific protocol being used (for example BankID
> >> >
https://www.bankid.com/) it may demand a certain callback format in
> >> > which
> >> > case we would have to implement a custom realm resource to handle the
> >> > callback.
> >>
> >> True - if there is a specific protocol to be used, we need to support
> >> the protocol. This is not aim of the quickstart that illustrates
> >> action token usage though.
> >>
> >> The biggest difference I see between the BankID and the action token
> >> quickstart is that for the async auth example, the realm resource code
> >> doesn't care (and possibly does not have to for its purpose) about
> >> authorization and validity of the request. For action token, you get
> >> these validations for free - as action tokens are signed and have
> >> validity timestamps, you can filter unauthorized requests without any
> >> further logic in the handler code.
> >>
> >> > Hynek - could you create a fork of my example that uses action
> >> > tokens?
> >>
> >> When the time permits, yes, it is rather straightforward:
> >>
> >> * External service (in this case CURL) would be given action token URL
> >> instead of realm resource URL.
> >>
> >> * Logic from BankIdCallbackResource would be removed and transformed
> >> into that of action token handler.
> >>
> >> The rest would remain the same.
> >
> >
> > Then there's the case that authentication session may not be available
> > on
> > the node handling the callback. Does action tokens already deal with
> > that?
> >
> >>
> >>
> >> --Hynek
> >>
> >> >> [1]
https://github.com/keycloak/keycloak-quickstarts/pull/37
> >> >>
> >> >> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva
> >> >> <psilva(a)redhat.com>
> >> >> wrote:
> >> >>>
> >> >>> Really nice !
> >> >>>
> >> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen
> >> >>> <sthorger(a)redhat.com>
> >> >>> wrote:
> >> >>>
> >> >>> > I gave it a go and implemented an "async"
authentication example.
> >> >>> > It's
> >> >>> > rather simple what happens is:
> >> >>> >
> >> >>> > * User authenticates with username only
> >> >>> > * Then a "waiting" page is displayed, which is
waiting for some
> >> >>> > external
> >> >>> > callback. This could be an app or whatever that verifies
the user
> >> >>> > then
> >> >>> > sends the callback. In the example a CURL command is
printed on
> >> >>> > sysout
> >> >>> > for
> >> >>> > the server which you can run to "simulate" the
callback from the
> >> >>> > app.
> >> >>> > * Once the callback is received the user is authenticated
without
> >> >>> > filling
> >> >>> > in password or any other credentials in the main browser
> >> >>> >
> >> >>>
> >> >>> Maybe you can use a SET [1], which is basically a JWT, in order
to
> >> >>> communicate authentication events between parties. For
instance,
> >> >>> send
> >> >>> additional data to the external callback about the
authentication
> >> >>> context
> >> >>> and receive back from the external callback information on how
to
> >> >>> proceed
> >> >>> with the authentication.
> >> >>>
> >> >>> [1]
https://tools.ietf.org/html/draft-hunt-idevent-token-03
> >> >>>
> >> >>>
> >> >>> >
> >> >>> >
https://github.com/stianst/authenticator-example
> >> >>> >
> >> >>> > Check it out here:
> >> >>> >
https://youtu.be/C09BpNIf4v8
> >> >>> >
> >> >>> > It's a bit hacky in the way it's implemented:
> >> >>> >
> >> >>> > * Using notes for "callback" is a bit strange
maybe?
> >> >>> > * Had to use custom realm resource for callback endpoint.
Is this
> >> >>> > strange?
> >> >>> > * Probably won't work for cross DC, but in 7.2 Hynek
has stuff
> >> >>> > that
> >> >>> > does
> >> >>> > that
> >> >>> > * No way to push change to browser, so have to pull every
2
> >> >>> > seconds.
> >> >>> > Maybe
> >> >>> > we could add a simple authentication event feature that
uses
> >> >>> > websockets
> >> >>> > and
> >> >>> > a small auth js lib to do the job of notification?
> >> >>> > _______________________________________________
> >> >>> > keycloak-dev mailing list
> >> >>> > keycloak-dev(a)lists.jboss.org
> >> >>> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>> >
> >> >>> _______________________________________________
> >> >>> keycloak-dev mailing list
> >> >>> keycloak-dev(a)lists.jboss.org
> >> >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> --Hynek
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
>
>
>
> --
>
> --Hynek