[Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
Ton Swieb
ton at finalist.nl
Thu Dec 10 10:56:54 EST 2015
Hi Marc,
Thanks.
The plugin functionality for the roundtrip in our Proof of Concept setup is
sufficient.
In the future I expect that we would need more flexibility in the mapping
of access token properties onto headers.
Regards,
Ton
2015-12-10 12:12 GMT+01:00 Marc Savy <marc.savy at redhat.com>:
> Sorry, missed out part of my sentence:
>
> If you feel the configuration options offered by the Keycloak OAuth2
> policy *are insufficient* let me know,
> and we can work out what changes might be possible to help.
>
> On 10/12/2015 11:10, Marc Savy wrote:
>
>> Nice! And understood - that should all work. If you feel the
>> configuration options offered by the Keycloak OAuth2 policy let me know,
>> and we can work out what changes might be possible to help.
>>
>> On 10/12/2015 11:06, Ton Swieb wrote:
>> > Yes we have set up Keycloak to delegate to a SAML IdP. So a user is
>> > redirected to a SAML IdP for login. After successfull login the user is
>> > automatically logged in in Keycloak and we can use the JS adapter to
>> > obtain an access token for accessing the Apiman gateway.
>> > We have this roundtrip working now, but we do still have some challenges
>> > with the mapping the SAML attributes to the Keycloak token.
>> >
>> >
>> > 2015-12-10 11:58 GMT+01:00 Marc Savy <marc.savy at redhat.com
>> > <mailto:marc.savy at redhat.com>>:
>> >
>> > Your JS snippet is indeed typical of what happens in the real
>> world -
>> > you generally wouldn't use a username and password in a plaintext
>> > JS app - instead you would use a client secret that can easily be
>> > regenerated (or login redirection for UI apps).
>> >
>> > What you're doing is the typical work-flow in JS; Keycloak's JS
>> library
>> > does the work behind the scenes to do the heavy lifting for you.
>> >
>> > Next step will be to test it with the SAML IdP instead of
>> standalone
>> > Keycloak, but I do not expect it to behave any differently.
>> >
>> >
>> > You mean you are setting up Keycloak to delegate to your SAML IdP?
>> >
>> > On 09/12/2015 16:02, Ton Swieb wrote:
>> >
>> > Hi Marc,
>> >
>> > I got it working, without the SAML IdP, using the Keycloak
>> > Javascript
>> > adapter.
>> >
>> > I used the Keycloak JS-Console example and extended it with a
>> > javascript
>> > function that does a call the apiman-gateway after I have a
>> > logged in
>> > session with Keycloak. Something like:
>> > var client = new XMLHttpRequest();
>> > client.open("GET", url, false);
>> > client.setRequestHeader("Accept",
>> "application/json");
>> > client.setRequestHeader("Authorization", "Bearer " +
>> > keycloak.token);
>> > client.send();
>> >
>> > The keycloak.token is available after a call to
>> > keycloak.login(). Both
>> > are part of the Keycloak javascript adapter.
>> >
>> > Underneath the Javascript adapter still does a call similair to
>> >
>> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token
>> > to retrieve the access token. With the difference that the
>> > grant_type
>> > used is authorization_code instead of password and a code is
>> > supplied
>> > instead of a username/password combination. I assume the code
>> is
>> > retrieved from the keycloak session. Not sure how it exactly
>> > works, but
>> > it works.
>> >
>> > Next step will be to test it with the SAML IdP instead of
>> standalone
>> > Keycloak, but I do not expect it to behave any differently.
>> >
>> > Regards,
>> >
>> > Ton
>> >
>> > 2015-12-08 19:00 GMT+01:00 Ton Swieb <ton at finalist.nl
>> > <mailto:ton at finalist.nl>
>> > <mailto:ton at finalist.nl <mailto:ton at finalist.nl>>>:
>> >
>> > Hi Marc,
>> >
>> > I am using the following setup:
>> > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP ->
>> > Keycloak
>> > (apiman realm) -> Client
>> > 2. Client -> apiman gateway -> Keycloak OAuth policy ->
>> > back-end ->
>> > apiman gateway -> Client
>> >
>> > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP.
>> > It is unclear to me why it matters which IdP I am using,
>> > because my
>> > assumption is that:
>> >
>> > * I end up with a valid Keycloak session within the
>> > apiman realm
>> > * the SAML 2.0 token should only be used by Keycloak to
>> > issue a
>> > login session to the client.
>> > * the client itself will never directly use anyhting
>> from
>> > the SAML
>> > 2.0 IdP, but should only use the stuff that Keycloak
>> > mapped from
>> > the SAML token onto its own token.
>> >
>> > I did ask the question on the keycloak mailinglist, but
>> from a
>> > different angle. I am afraid the solution for my problem
>> > will be
>> > somewhere in between.
>> > Any help from your site is greatly appreciated :-)
>> >
>> > Regards,
>> >
>> > Ton
>> >
>> >
>> > Message: 5
>> > Date: Tue, 8 Dec 2015 16:58:26 +0000
>> > From: Marc Savy <marc.savy at redhat.com
>> > <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>> > <mailto:marc.savy at redhat.com>>>
>> > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get
>> > bearer token
>> > for logged in user without using
>> username/password
>> > To: apiman-user at lists.jboss.org
>> > <mailto:apiman-user at lists.jboss.org>
>> > <mailto:apiman-user at lists.jboss.org
>> > <mailto:apiman-user at lists.jboss.org>>
>> > Message-ID: <56670C32.3060000 at redhat.com
>> > <mailto:56670C32.3060000 at redhat.com>
>> > <mailto:56670C32.3060000 at redhat.com
>> > <mailto:56670C32.3060000 at redhat.com>>>
>> > Content-Type: text/plain; charset=UTF-8; format=flowed
>> >
>> > To expand on that - depending on exactly what type of IdP
>> (and
>> > specifically which technology) you were delegating to, it
>> > may be
>> > possible to do what you're asking - or you may need to
>> write
>> > something custom.
>> >
>> > Can you provide more detail?
>> >
>> > Also, if you have very specific Keycloak questions you
>> > might be best
>> > served on the keycloak-user mailing list, which is
>> > extremely active
>> > (https://lists.jboss.org/mailman/listinfo/keycloak-user).
>> >
>> > On 08/12/2015 16:53, Marc Savy wrote:
>> > > Hi Ton,
>> > >
>> > > I'm not quite sure what you mean, but I think what
>> > you're asking
>> > for is
>> > > brokerage/delegation in the form:
>> > >
>> > > 1. Client <-> Keycloak <-> Other IdP.
>> > > 2. Client <-> apiman gateway
>> > >
>> > > Regards,
>> > > Marc
>> > >
>> > > On 08/12/2015 15:28, Ton Swieb wrote:
>> > > > Hi,
>> > > >
>> > > > I would like to secure my api's using the Keycloak
>> > OAuth2 policy.
>> > > > Similair to what is described in the blog post of
>> Marc
>> > Savy:
>> > > >
>> >
>> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html
>> > > >
>> > > >
>> > > > Only with the difference that Keycloak delegates the
>> > login to a
>> > third
>> > > > party IdP. After logging in at this third party IdP I
>> > end up
>> > with an
>> > > > active session in the Apiman UI (the apiman realm of
>> > Keycloak).
>> > > >
>> > > > Now I am wondering how to get the bearer token,
>> > because I do
>> > not have a
>> > > > username/password combination I can use to make a
>> call
>> > like:
>> > > >
>> > > > |curl -X POST
>> > > >
>> >
>> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token
>> > > > -H "Content-Type: application/x-www-form-urlencoded"
>> -d
>> > > > "username=rincewind" -d 'password=apiman' -d
>> > 'grant_type=password' -d
>> > > > 'client_id=apiman'|
>> > > >
>> > > > Because the username/password combination is linked
>> to the
>> > third party
>> > > > IdP and not to Keycloak itself.
>> > > >
>> > > > Is there another way to obtain the bearer token?
>> > > >
>> > > > Perhaps this is aquestion which I should address at
>> > the keycloak
>> > > > mailinglist. I will try to ask the question there as
>> well.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Ton
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > Apiman-user mailing list
>> > > > Apiman-user at lists.jboss.org
>> > <mailto:Apiman-user at lists.jboss.org>
>> > <mailto:Apiman-user at lists.jboss.org
>> > <mailto:Apiman-user at lists.jboss.org>>
>> > > > https://lists.jboss.org/mailman/listinfo/apiman-user
>> > > >
>> > >
>> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151210/1cf64506/attachment-0001.html
More information about the Apiman-user
mailing list