[openstack-dev] [Keystone] Bug in federation

Marco Fargetta marco.fargetta at ct.infn.it
Wed Dec 24 18:01:13 UTC 2014

Hi John,
the problem is not to establish which variable has the correct information but the association
between IDP and URL. In OS-Federation you define an authentication URL per IDP and protocol
and it is supposed to use the specified IDP and protocol for authenticate. Nevertheless, during the
authentication there is not code to check if the IDP and protocol are the one specified for the URL
and in the apache configuration for Juno there was no configuration in the apache side to bind the
IDP with the URL.

Therefore, you need to add something in OS_Federation to perform this control using the variable you
are proposing or others.


> On 24 Dec 2014, at 15:15, John Dennis <jdennis at redhat.com> wrote:
> Can't this be solved with a couple of environment variables? The two
> keys pieces of information needed are:
> 1) who authenticated the subject?
> 2) what authentication method was used?
> There is already precedence for AUTH_TYPE, it's used in AJP to
> initialize the authType property in a Java Servelet. AUTH_TYPE would
> cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps
> there could be a convention that AUTH_TYPE could carry extra qualifying
> parameters much like HTTP headers do. The first token would be the
> primary mechanism, e.g. saml, negotiate, x509, etc. For authentication
> types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra
> parameter would qualify the actual mechanism used. For SAML that
> qualifying extra parameter could be the value from AuthnContextClassRef.
> Item 1 could be covered by a new environment variable AUTH_AUTHORITY.
> If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would
> be the KDC. For SAML it would probably be taken from the
> AuthenticatingAuthority element or the IdP entityID.
> I'm not sure I see the need for other layers to receive the full SAML
> assertion and validate the signature. One has to trust the server you're
> running in. It's the same concept as trusting REMOTE_USER.
> -- 
> John
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Eng. Marco Fargetta, PhD

Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy

EMail: Marco.Fargetta at ct.infn.it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141224/4eb08f3b/attachment.bin>

More information about the OpenStack-dev mailing list