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