[Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password

Wed Dec 16 09:33:41 EST 2015

Hi Ton,

This feature is now implemented, and is on master. It works with
standard and custom claims (custom token properties).

I think custom claims are likely a nice solution to your problem.

If you want to test drive it, please check out the apiman-plugins repo,
build with `mvn clean install`, and in the plugin management section
reload your keycloak-aouth plugin.

Otherwise, it'll be out with 1.2.0 :)

For more info, see: https://github.com/apiman/apiman-plugins/pull/43

Regards,
Marc

On 10/12/2015 16:41, Marc Savy wrote:
> Ton,
>
> I've added a JIRA for your feature request/enhancement - https://issues.jboss.org/browse/APIMAN-834
>
> Marc
>
> ----- Original Message -----
> From: "Ton Swieb" <ton at finalist.nl>
> To: "Marc Savy" <marc.savy at redhat.com>
> Cc: apiman-user at lists.jboss.org
> Sent: Thursday, 10 December, 2015 3:56:54 PM
> Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
>
> 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
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> 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
>