settingsLogin | Registersettings

[openstack-dev] [keystone federation] some questions about keystone IDP with SAML supported

0 votes

hello, keystoners. please help me

Here is my use case:
1. use keystone as IDP , supported with SAML
2. keystone integrates with LDAP
3. we use a java application as Service Provider, and to integrate it with keystone IDP.
4. we use a keystone as Service Provider, and to integrate it withe keystone IDP.

The problems:
in the k2k federation case, keystone service provider requests authentication info with IDP via Shibboleth ECP.
in the java application, we use websso to request IDP, for example:
idpssoendpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso
but, the java redirect the sso url , it will return 404 error.
so, if we want to integrate a java application with keystone IDP, should we need to support ECP in the java application?

here is my some references:
1. http://docs.openstack.org/developer/keystone/configure_federation.html
2. http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo
3. http://docs.openstack.org/developer/keystone/extensions/federation.html
https://gist.githubusercontent.com/zaccone/3c3d4c8f39a19709bcd7/raw/d938f2f9d1cf06d29a81d57c8069c291fed66cab/k2k-env.sh
https://gist.githubusercontent.com/zaccone/4bbc07d215c0047738b4/raw/75295fe32df88b24576ece69994270dc4eb19a6e/k2k-ecp-client.py
my keystone version is kilo

help me, thanks__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

asked Oct 14, 2015 in openstack-dev by wyw (160 points)   1 1

4 Responses

0 votes

Hello,

On 14.10.2015 13:10, wyw wrote:
hello, keystoners. please help me

Here is my use case:
1. use keystone as IDP , supported with SAML

Remember that Keystone is not a fully fledged Identity Provider. For
instance it cannot handle WebSSO. To be even more specific it will only
handle "IdP Initiated authentication workflow" and it's one of the
variant SAML2 authentication work.

  1. keystone integrates with LDAP
  2. we use a java application as Service Provider, and to integrate it
    with keystone IDP.
  3. we use a keystone as Service Provider, and to integrate it withe
    keystone IDP.

Did you try that already? Did it work?

The problems:
in the k2k federation case, keystone service provider requests
authentication info with IDP via Shibboleth ECP.

Yes. Why is that a problem? K2K architecture assumes two Keystones -
Keystone-IdP and Keystone-SP . Communication between them leverages on
SAML2 and ECP.

in the java application, we use websso to request IDP, for example:

as mentioned earlier - no websso in keystone-idp.

idpssoendpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso
but, the java redirect the sso url , it will return 404 error.
so, if we want to integrate a java application with keystone IDP,
should we need to support ECP in the java application?

pretty much - yes! Luckily for you the reference libraries (shibboleth)
are written in Java so it should be easier to integrate with your
application.

I hope I did! :-)

--
Marek Denis


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 14, 2015 by Marek_Denis (940 points)   1 3
0 votes

On 10/14/2015 07:10 AM, wyw wrote:
hello, keystoners. please help me

Here is my use case:
1. use keystone as IDP , supported with SAML
2. keystone integrates with LDAP
3. we use a java application as Service Provider, and to integrate it
with keystone IDP.
4. we use a keystone as Service Provider, and to integrate it withe
keystone IDP.

Keystone is not an identity provider, or at least it's trying to get out
of that business, the goal is to have keystone utilize actual IdP's
instead for authentication.

K2K utilizes a limited subset of the SAML profiles and workflow.
Keystone is not a general purpose SAML IdP supporting Web SSO.

Keystone implements those portions of various SAMLv2 profiles necessary
to support federated Keystone and derive tokens from federated IdP's.
Note this distinctly different than Keystone being a federated IdP.

The problems:
in the k2k federation case, keystone service provider requests
authentication info with IDP via Shibboleth ECP.

Nit, "Shibboleth ECP" is a misnomer, ECP (Enhanced Client & Proxy) is a
SAMLv2 profile, a SAML profile Shibboleth happens to implement, however
there other SP's and IdP's that also support ECP (e.g. mellon, Ipsilon)

in the java application, we use websso to request IDP, for example:
idpssoendpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso
but, the java redirect the sso url , it will return 404 error.
so, if we want to integrate a java application with keystone IDP,
should we need to support ECP in the java application?

You're misapplying SAML, Keystone is not a traditional IdP, if it were
your web application could use SAML HTTP-Redirect or it could also
function as an ECP client, but not against Keystone. Why? Keystone is
not a general purpose federated IdP.

--
John


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 14, 2015 by John_Dennis (1,880 points)   1 3
0 votes

On 10/14/2015 11:58 AM, Marek Denis wrote:
pretty much - yes! Luckily for you the reference libraries (shibboleth)
are written in Java so it should be easier to integrate with your
application.

Only the Shibboleth IdP is written in Java. Shibboleth the SP is written
in C++. If you're trying to implement an ECP client you'll probably find
more support in the C++ SP implementation libraries for what you need.

Actually writing an ECP client is not difficult, you could probably
cobble one together pretty easily from the standard Java libraries. An
ECP client only needs to be able to parse and generate XML and
communicate via HTTP. It does not need to be able to read or generate
any SAML specific XML because an ECP client encapsulates the SAML in
other XML (e.g. SOAP).

--
John


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 14, 2015 by John_Dennis (1,880 points)   1 3
0 votes

Many Thanks!

John, I agree with you. Keystone is not a general purpose federated IdP.
"Web application could use SAML HTTP-Redirect or it could also function as an ECP client."

Now Keystone supports token, saml2, oauth1. There is aslo a keystone plugin project try to support oauth2. But Keystone's goal is not to support Web SSO

BTW, if I still want to utilize Keystone, such as token authentication and SCIM and integration with LDAP functionalities.
Could I use some SAMLv2 SSO Server, such as UAA or WSO2 Identity Server , to integrate with Keystone?

the case maybe like this:
A Java Service Provider ==SAMLv2 SSO==>UAA/WSO2 Identity Server
UAA/WSO2 Identity Server ==IDP integrate with==> Keystone ==datastore==>LDAP

Certainly, A Java Service Provider ==> UAA/WSO2 Identity Server ==> LDAP
maybe make sense.

I means , Could we integrate any SSO Server for Keystone solution?
I think it can do by implementing a java websso service, that integrated with Keystone's token auth. Although it is not a standard SAMLv2 IDP solution.

Java SP ==sso==> Java WEBSSO Service(RestAPI) ==token==> Keystone(token auth/SCIM API)

Thanks for more help.

------------------ 原始邮件 ------------------
发件人: "John Dennis";jdennis@redhat.com;
发送时间: 2015年10月15日(星期四) 凌晨1:05
收件人: "OpenStack Development Mailing List (not for usage questions)"openstack-dev@lists.openstack.org; "wyw"93425129@qq.com;

主题: Re: [openstack-dev] [keystone federation] some questions aboutkeystone IDP with SAML supported

On 10/14/2015 07:10 AM, wyw wrote:
hello, keystoners. please help me

Here is my use case:
1. use keystone as IDP , supported with SAML
2. keystone integrates with LDAP
3. we use a java application as Service Provider, and to integrate it
with keystone IDP.
4. we use a keystone as Service Provider, and to integrate it withe
keystone IDP.

Keystone is not an identity provider, or at least it's trying to get out
of that business, the goal is to have keystone utilize actual IdP's
instead for authentication.

K2K utilizes a limited subset of the SAML profiles and workflow.
Keystone is not a general purpose SAML IdP supporting Web SSO.

Keystone implements those portions of various SAMLv2 profiles necessary
to support federated Keystone and derive tokens from federated IdP's.
Note this distinctly different than Keystone being a federated IdP.

The problems:
in the k2k federation case, keystone service provider requests
authentication info with IDP via Shibboleth ECP.

Nit, "Shibboleth ECP" is a misnomer, ECP (Enhanced Client & Proxy) is a
SAMLv2 profile, a SAML profile Shibboleth happens to implement, however
there other SP's and IdP's that also support ECP (e.g. mellon, Ipsilon)

in the java application, we use websso to request IDP, for example
idpssoendpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso
but, the java redirect the sso url , it will return 404 error.
so, if we want to integrate a java application with keystone IDP,
should we need to support ECP in the java application?

You're misapplying SAML, Keystone is not a traditional IdP, if it were
your web application could use SAML HTTP-Redirect or it could also
function as an ECP client, but not against Keystone. Why? Keystone is
not a general purpose federated IdP.

--
John__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Oct 15, 2015 by wyw (160 points)   1 1
...