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：
idp_sso_endpoint = 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
