[keycloak-dev] Async authentication example

[Stian Thorgersen]

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 at 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 at redhat.com>
> wrote:
> >
> >
> > On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> >>
> >> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at 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 at redhat.com
> >
> >> >> wrote:
> >> >>>
> >> >>> Really nice !
> >> >>>
> >> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen
> >> >>> <sthorger at 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 at lists.jboss.org
> >> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>> >
> >> >>> _______________________________________________
> >> >>> keycloak-dev mailing list
> >> >>> keycloak-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> --Hynek
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
>
>
>
> --
>
> --Hynek
>