Open Stack

On 01/27/2014 12:26 PM, Marek Denis wrote:
> Dear all,
>
> We have Identity Provider and mapping CRUD operations already merged, 
> so it's a good point to prepare Keystone and Apache to handle SAML (as 
> a starter) requests/responses.
> For the next OpenStack release it'd be the Apache that handles SAML 
> communication. In order to force SAML authentication, an admin defines 
> so called 'protected resources', hidden behind certain URLs. In order 
> to get access to aforementioned resources a SAML authenticated session 
> is required. In terms of Keystone and federation this 'resource' would 
> be just a token, ready to be later used against other OpenStack 
> services. For obvious reasons we cannot make mod_shib watch all the 
> Keystone URLs clients can access, so I think a dedicated URL should be 
> used. That's right, a client who'd want to grab a token upon SAML 
> authn would need to hit 
> https://keystone:5000/v3/OS-FEDERATION/tokens/identity_provider/<idp>/protocol/<protocol> 
> .Such a URL would albo be kind of dynamic, because this would later 
> let Keystone distinguish* what (already registered) IdP and federation 
> protocol (SAML, OpenID, etc) is going to be used .
>
> A simplified workflow could look like this:
>
>
> Pre-req: Apache frontend is  configured to protect URLs matching regex 
> /OS-FEDERATION/tokens/identity_provider/(.*?)/protocol/(.*?)
>
> 1) In order to get a valid token upon federated authentication a 
> client enters protected resource, for instance 
> https://keystone:5000/v3/OS-FEDERATION/tokens/identity_provider/{idp}/protocol/{protocol}
> 2) After the client is authenticated (with ECP/similar extension) the 
> request enters Keystone public pipeline.
> 3) Apache modules  store parsed parameters from a SAML assertion in a 
> wsgi environment,
> 4) A class inheriting from wsgi.Middleware checks whether the 
> REQUEST_URL (or similar) environment variable matches aforementioned 
> regexp (e.g. /OS-FEDERATION/tokens/identity_provider/.*?/protocol/.*?) 
> and if the match is positive, fetches env parameters starting with 
> certain value (a prefix configurable in the keystone.conf, say 'ADFS_' 
> ). The parameters are stored as a dictionary and passed in a 
> structure, later available to other filters/middleware objects in the 
> pipeline (TO BE CONFIRMED, MAYBE REWRITING PARAMS IS NOT REQUIRED).
> 5) keystone/contrib/federation/routers.py has defined URL routes and 
> fires keystone/contrib/federation/controllers.py methods that fetch 
> IdP, protocol entities as well as the corresponding mapping entity 
> with the mapping rules included. The rules are applied  on the 
> assertion parameters and list of local users/groups is issued. The 
> OpenStack token is generated, stored in the DB and returned to the 
> user (formed as a valid JSON response).
> 6) The token can now be used for next operations on the OpenStack cloud.
>
>
> *)
> At first I though the dynamic URLs 
> (OS-FEDERATION/tokens/identity_provider/(.*?)/protocol/(.*?)) could be 
> replaced with a one static, and information about the IdP and protocol 
> could be sent as a HTTP POST input, but from what I have already 
> noticed after the client is redirected to the IdP (and to the SP 
> again) the initial input is lost.
>
>
> I am looking forward to hear feedback from you.
>
> Thanks,
>


This sounds sane.  We'd like to keep the Param rewriting as an option, 
but if it breaks things, could be done phase2.

To be clear, are you going to use mod_mellon as the Apache Auth module?