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