Open Stack

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