Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
10:02 a.m.
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>:
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>
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
Message-ID: <56670C32.3060000(a)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
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
4:58 a.m.
New subject: Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
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>>:
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>>
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>
Message-ID: <56670C32.3060000(a)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>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
5:06 a.m.
New subject: 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>:
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>>:
>
> 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>>
> 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>
> Message-ID: <56670C32.3060000(a)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>
> > > https://lists.jboss.org/mailman/listinfo/apiman-user
> > >
> >
>
>
>
5:10 a.m.
New subject: Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
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(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
> >
>
5:12 a.m.
New subject: Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
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(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
> > >
> >
>
>
>
>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
9:56 a.m.
New subject: 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(a)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(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
> > > >
> > >
> >
> >
> >
> >
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
10:41 a.m.
New subject: Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
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(a)finalist.nl>
To: "Marc Savy" <marc.savy(a)redhat.com>
Cc: apiman-user(a)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(a)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(a)redhat.com
<mailto: marc.savy(a)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(a)finalist.nl >
<mailto: ton(a)finalist.nl <mailto: ton(a)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(a)redhat.com > <mailto: marc.savy(a)redhat.com
<mailto: marc.savy(a)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(a)lists.jboss.org >
<mailto: apiman-user(a)lists.jboss.org
<mailto: apiman-user(a)lists.jboss.org >>
Message-ID: < 56670C32.3060000(a)redhat.com
<mailto: 56670C32.3060000(a)redhat.com >
<mailto: 56670C32.3060000(a)redhat.com
<mailto: 56670C32.3060000(a)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(a)lists.jboss.org >
<mailto: Apiman-user(a)lists.jboss.org
<mailto: Apiman-user(a)lists.jboss.org >>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
8:33 a.m.
New subject: Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password
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(a)finalist.nl>
To: "Marc Savy" <marc.savy(a)redhat.com>
Cc: apiman-user(a)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(a)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(a)redhat.com
> <mailto: marc.savy(a)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(a)finalist.nl >
> <mailto: ton(a)finalist.nl <mailto: ton(a)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(a)redhat.com > <mailto: marc.savy(a)redhat.com
> <mailto: marc.savy(a)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(a)lists.jboss.org >
> <mailto: apiman-user(a)lists.jboss.org
> <mailto: apiman-user(a)lists.jboss.org >>
> Message-ID: < 56670C32.3060000(a)redhat.com
> <mailto: 56670C32.3060000(a)redhat.com >
> <mailto: 56670C32.3060000(a)redhat.com
> <mailto: 56670C32.3060000(a)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(a)lists.jboss.org >
> <mailto: Apiman-user(a)lists.jboss.org
> <mailto: Apiman-user(a)lists.jboss.org >>
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>
>
>
>
>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
3773
days inactive
3780
days old
7 comments
3 participants
participants (3)
-
Marc Savy -
Marc Savy -
Ton Swieb