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

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(a)redhat.com <mailto:marc.savy@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(a)finalist.nl <mailto:ton@finalist.nl> <mailto:ton@finalist.nl <mailto:ton@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(a)redhat.com <mailto:marc.savy@redhat.com> <mailto:marc.savy@redhat.com <mailto:marc.savy@redhat.com>>> Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password To: apiman-user(a)lists.jboss.org <mailto:apiman-user@lists.jboss.org> <mailto:apiman-user@lists.jboss.org <mailto:apiman-user@lists.jboss.org>> Message-ID: <56670C32.3060000(a)redhat.com <mailto:56670C32.3060000@redhat.com> <mailto:56670C32.3060000@redhat.com <mailto:56670C32.3060000@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... > > > > > > 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(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> <mailto:Apiman-user@lists.jboss.org <mailto:Apiman-user@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/apiman-user > > >