[openstack-dev] [Keystone] Bug in federation

David Chadwick d.w.chadwick at kent.ac.uk
Wed Dec 24 15:37:22 UTC 2014

HI John

On 24/12/2014 14:15, John Dennis 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?

AUTH_AUTHORITY or similar would stop wrong configuration of Apache if it
was set by the protocol plugin module from the protocol messages it
received. But it may take time for all plugin suppliers to adopt this
and implement it.

> 2) what authentication method was used?

Its not the authentication method that is being questioned (could be
un/pw, two factor or any other method), but rather the federation
protocol that was used. So I dont think AUTH-TYPE is the right parameter
for what is required.

> 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.

Not quite. A badly configured Apache would not (should not) effect
REMOTE_USER as this should be set by the authn plugin. Currently we have
nothing to check that Apache was correctly configured



More information about the OpenStack-dev mailing list