5:11 a.m.
Hi,
I have Keycloak as an identity broker for the a SAML SSO service. Login via
the browser works great. Now, I want to call the APIs of the SP's
application directly using python or java. Are these steps documented
somewhere? Should my python script send 2 authentication requests (e.g.
first to Keycloak and then to the real IDP)?
Thanks,
Pieter
www.thehyve.nl
E pieter(a)thehyve.nl
We empower scientists by building on open source software
10:36 a.m.
On 11/27/2017 06:11 AM, Pieter Lukasse wrote:
Hi,
I have Keycloak as an identity broker for the a SAML SSO service. Login via
the browser works great. Now, I want to call the APIs of the SP's
application directly using python or java. Are these steps documented
somewhere? Should my python script send 2 authentication requests (e.g.
first to Keycloak and then to the real IDP)?
The standard way to perform SAML authentication for command line clients
is to utilize the SAML ECP (Enhanced Client & Proxy) profile. ECP *must*
be supported on the SP, Keycloak already has the necessary components
for ECP and has been tested.
I have a couple of Python scripts that use ECP and Openstack uses ECP in
Python as well. However my ECP python code is not in a state for general
consumption. Writing an ECP client is not hard, I'd suggest it be
integrated with python-requests.
SAML2 Profile for ECP (Section 4.2) defines these steps for an ECP
transaction:
1. ECP issues HTTP Request to SP
2. SP issues <AuthnRequest> to ECP using PAOS
3. ECP determines IdP
4. ECP conveys <AuthnRequest> to IdP using SOAP
5. IdP identifies principal
6. IdP issues <Response> to ECP, targeted at SP using SOAP
7. ECP conveys <Response> to SP using PAOS
8. SP grants or denies access to principal
Before you go much further you will want to make sure your SP supports
PAOS, this can easily be determined by examining the SP metadata and
looking for an ACS (Assertion Consumer Service) endpoint with the paos
binding. If your SP does not support PAOS you're likely limited to
browser based access only.
--
John
2:17 p.m.
On 11/27/2017 11:36 AM, John Dennis wrote:
I have a couple of Python scripts that use ECP and Openstack uses ECP
in
Python as well. However my ECP python code is not in a state for general
consumption. Writing an ECP client is not hard, I'd suggest it be
integrated with python-requests.
Oh, I forgot to mention the pysaml2 library has an implementation of an
ECP client in ecp_client.py. I have not actually used this code so I
can't vouch for it, but it probably would get you a long ways down the
road to using ECP in Python.
--
John
4:43 a.m.
Thanks for your reply John.
One question regarding your workflow: with IdP do you mean Keycloak or the
brokered IdP?
Thanks,
Pieter
www.thehyve.nl
E pieter(a)thehyve.nl
T +31(0)30 700 9713
M +31(0)6 28 18 9540
Skype pieter.lukasse
We empower scientists by building on open source software
2017-11-27 21:17 GMT+01:00 John Dennis <jdennis(a)redhat.com>:
On 11/27/2017 11:36 AM, John Dennis wrote:
> I have a couple of Python scripts that use ECP and Openstack uses ECP in
> Python as well. However my ECP python code is not in a state for general
> consumption. Writing an ECP client is not hard, I'd suggest it be
> integrated with python-requests.
>
Oh, I forgot to mention the pysaml2 library has an implementation of an
ECP client in ecp_client.py. I have not actually used this code so I can't
vouch for it, but it probably would get you a long ways down the road to
using ECP in Python.
--
John
11:01 a.m.
On 12/01/2017 05:43 AM, Pieter Lukasse wrote:
Thanks for your reply John.
One question regarding your workflow: with IdP do you mean Keycloak or
the brokered IdP?
I'm not sure I understand the question because when you authenticate
against an IdP that is the only IdP you're aware of. If the IdP brokers
(delegates) to another IdP to satisfy your request that process is
invisible to you (with the possible exception the response may indicate
who the ultimate authority was, I can't recall off the top of my head if
the protocol includes this information or not). But from a protocol
point of view you're only ever talking to one IdP.
--
John
3:01 a.m.
Hi John,
what about this workflow:
http://www.keycloak.org/docs/3.4/server_admin/#_identity_broker_overview ?
The browser will interact with both the broker and the IDP. Won't the
script have to do something similar?
Thanks,
Pieter
www.thehyve.nl
E pieter(a)thehyve.nl
T +31(0)30 700 9713
M +31(0)6 28 18 9540
Skype pieter.lukasse
We empower scientists by building on open source software
2017-12-01 18:01 GMT+01:00 John Dennis <jdennis(a)redhat.com>:
On 12/01/2017 05:43 AM, Pieter Lukasse wrote:
> Thanks for your reply John.
>
> One question regarding your workflow: with IdP do you mean Keycloak or
> the brokered IdP?
>
I'm not sure I understand the question because when you authenticate
against an IdP that is the only IdP you're aware of. If the IdP brokers
(delegates) to another IdP to satisfy your request that process is
invisible to you (with the possible exception the response may indicate who
the ultimate authority was, I can't recall off the top of my head if the
protocol includes this information or not). But from a protocol point of
view you're only ever talking to one IdP.
--
John
2581
days inactive
2588
days old
5 comments
2 participants
participants (2)
-
John Dennis -
Pieter Lukasse