Federated Identity Workshop Coming up...

This is a plug for a workshop on Federated Identity Management for Scientific Collaborations coming at RAL 2-3 November:

http://indico.cern.ch/conferenceDisplay.py?ovw=True&confId=157486

It's a follows the first of it's kind held earlier this year held at CERN and brought together experts in the field and representatives from a range of different scientific communities to present the state of play for federated identity management in each of the various fields and draw together a roadmap for future development.   See the minutes for a full account.

Picking out just a few themes that were of interest to me: inter-federation trust came up a number of times and the need for services to translate credentials from one domain to another.  I read that as a healthy sign that a) various federated identity management systems have bed down and become established and b), that there is not a fight of competing security technologies for one to take over all, rather a facing up to realities of how can we make it work so that these co-exist along side each other.

Credential translation brings in another two interesting issues: provenance and levels of assurance that actually also arose independently in some of the talks and discussions.  If I have a credential that is as a result of a translation of another credential from a different domain how much information is transferred between the two, is it lossy are the identity concepts and various attributes semantically the same?   The same issues arise perhaps to a lesser degree with delegation technologies. 

Levels of assurance is another issue that is surely going to crop up more and more as different authentication mechanisms are mixed together in systems: the same user can enter a federated system with different methods how do we ensure that they are assigned access rights accordingly.   Some complicated issues to tackle but the fact that they can begin to be addressed shows the progress that has been made building on the foundations of established federated systems.

Java SSL Whitelisting of Peer Certificate Subject Names

Helping a colleague just today has reminded me to finish this post drafted a long time ago. Last year I was dipping into the Java SSL libraries to write a short piece of code to make a call to a service running over HTTPS where mutual authentication is required. - The client authenticates the server based on the server's X.509 certificate passed in the SSL handshake but in addition, the client must pass a certificate to enable the server to authenticate it the client.

By default, the Java SSL trust manager will trust peer certificates provided that they are issued by any of the CAs (Certificate Authorities) whose certificates appear in the default trust store for the JVM.   It's possible to customise the trust manager to use a given trust store to give more fine grained control but what if we want to trust only a certain subset of certificates issued by a given CA or CAs?  

One way to achieve this is to whitelist based on the peer certificate DN or Distinguished Name.   This is something that is straightforward to do on the server side with, for example, Apache using the SSLRequire directive. It's also a practice used in Grid computing authorisation middleware with ACLs (Access Control Lists).  Rather than the protection of some server-side resource, the problem to solve in this case is a client invocation.

Returning to the SSL API then, this can be achieved by implementing javax.net.ssl.X509TrustManager interface. The key method for client side checking of server certificates is checkServerTrusted. The relevant hooks can be set in here to check the peer certificate against a whitelist:

    public void checkServerTrusted(X509Certificate[] chain, String authType)
        throws CertificateException {
     
        // Default trust manager may throw a certificate exception
        pkixTrustManager.checkServerTrusted(chain, authType);
        
        // If chain is OK following previous check, then execute whitelisting 
        // of DN
        X500Principal peerCertDN = null;
  
        if (certificateDnWhiteList == null || 
            certificateDnWhiteList.isEmpty())
            return;
  
        int basicConstraints = -1;
        for (X509Certificate cert : chain) {
            // Check for CA certificate first - ignore if this is the case
            basicConstraints = cert.getBasicConstraints();
            if (basicConstraints > -1)
                continue;

            peerCertDN = cert.getSubjectX500Principal();
            for (X500Principal dn : certificateDnWhiteList)
                if (peerCertDN.getName().equals(dn.getName()))
                    return;

            throw new CertificateException("No match for peer certificate \"" + 
  peerCertDN + "\" against Certificate DN whitelist");
        }
    }

pkixTrustManager is the default trust manager whilst certificateDnWhiteList is a list of accepted DNs as X500Principal types.  These can be initialised in the classes' constructor from a properties file or some other input.  The pkixTrustManager.checkServerTrusted call applies the default verification of the peer's certificate based on the CA certificates present in the client's trust store. If this succeeds, a loop then iterates over the certificate chain returned by the peer skipping any CA certificates*.  Once the peer certificate is found, its DN is extracted and checked against the whitelist. If matched, it returns silently to the caller indicating all is OK. If no match is found, a CertificateException is thrown to indicate that the peer certificate is not in the accepted list of DNs.  This could easily be extended to do more sophisticated matching for example using regular expressions.

This technical article provides some more background (scroll down a long way to the Trust Manager heading).  The full source for the example above is available here.

[* The peer can of course pass back not only its own certificate, but any intermediate CA certificates needed to complete the chain of trust to a root CA certificate held by the client.]

Proxy certificates and delegation with netCDF Beta release

I've written previously about the extensions to the netCDF C API to enable SSL client based authentication.  It's been great to see how something slotted in at the base of a software stack filters down to benefit all the dependents: colleagues have been testing Ferret, ncview and Python bindings built against the updated libraries and used to query ESG-secured OPeNDAP services.  This links with another thread, the MashMyData project extends this SSL client based authentication mechanism from EECs (End Entity Certificates) - the current currency for short lived credentials in ESGF (Earth System Grid Federation) - to RFC3820 proxy certificates.   This is necessitated by the need for delegation in chain of operations in our use case: a chain linking a portal to an OGC Web Processing Service which itself calls an OPeNDAP service.  So, on to trying out the netCDF C client with a proxy certificate:

• Get ESG-enabled netCDF - now in 4.1.2 beta2
• build simple client against this version of the library
• Get  EEC and delegate (need Globus Toolkit for this example)

So expanding the last step:

1) Get short lived EEC from home MyProxy server:

$ myproxy-logon -s <my idp's myproxy host address> -o user.pem -b

2) Delegate to obtain proxy certificate:

$ grid-proxy-init -cert user.pem -key user.pem -out ./credentials.pem -rfc

3) Update netCDF configuration to pick up credentials:

CURL.VERBOSE=1
CURL.COOKIEJAR=.dods_cookies
CURL.SSL.VALIDATE=1
CURL.SSL.CERTIFICATE=<path>/credentials.pem
CURL.SSL.KEY=<path>/credentials.pem
CURL.SSL.CAPATH=<home path>.globus/certificates

Calling the netCDF client makes the underlying Curl library invocation and correctly passes the certificate chain comprising proxy certificate and EEC that issued it (grid-proxy-init step).  The OPeNDAP server and associated security middleware is correctly configured to accept proxy certificates.  I get my data back :).

It's nice when it just works

Last week we deployed the full access control infrastructure with our TDS (THREDDS Data Server) part of the Data Node component we are hosting at the BADC as part of the Earth System Grid Federation (ESGF).  What's been pleasing is that we have been able to mix independent implementations together and yet combine them easily in a working system.

The ESGF in terms of software implementation is predominantly Java based but within the context of access control there is a parallel Python based 'NDG Security' implementation here.     We now have TDS deployed too but hooked up to the same system.   This follow-ups from a previous post on the authorisation infrastructure for ESG where I showed PyDAP, a Python implementation of OPeNDAP deployed with our authorisation system.  TDS is of course Java based and we run it within Tomcat fronted with a servlet based authorisation filter.   The common interface to the authorisation system is via a SAML web service callout from the filter to an Authorisation Service.   ESGF has a Java based Authorisation Service implementation but here we've deployed with a Python based one from NDG Security which shares the same interface.  Plugging in the TDS to this was simply a question of making the connection settings and adding the additional rules needed in the XACML policy.

So below, a user's NetCDF (could equally be a browser) client can talk to two apps PyDAP and TDS to make OPeNDAP queries.  PyDAP is deployed with mod_wsgi / Apache.     Each service is fronted by an authorisation filter (In practice, authentication filters too but omitted here for simplicity).   The respective filters intercept requests and query the authorisation service to make an access control decision.   The Authorisation Service is itself a Python app is also running under mod_wsgi/Apache.

Within the Authorisation Service, a context handler translates the incoming SAML decision request query to XACML (yes, XACML could have been used instead between the filters and Authorisation Service) and feeds the request to the Policy Decision Point.  The PDP has a XACML policy fed to it at start-up.  When making an access decision, it can also query for additional attributes by requesting the context handler query the Policy Information Point.  The PIP can query for federation wide attributes from an Attribute Service at PCMDI.  PCMDI have a key role administering access in the federation.  The PDP makes its decision and a response is sent via the Context handler back to the filter fronting the respective app.

Only as strong as the weakest link in the chain

A security system is only as strong as the weakest link in the chain to paraphrase a well known saying.   There can be lots of links to think about in a federated security system.  How do you ensure a thorough analysis and an acceptable baseline level of security?  The NIST levels of assurance framework provides a valuable metric against which to make an assessment.

One argument that could made for example is that we only need an authentication mechanism at some low level of assurance, say X  (worse still - no analysis is made and there's an implicit assumption!).  You develop your system to meet that requirement and deploy it accordingly but what happens when you find that your system needs to secure slightly more sensitive data?  Your original analysis breaks down and your system is no longer fit for purpose.  With a large federated system, that's potentially a lot of infrastructure to have to tear down and re-implement and deploy.  Wouldn't it have been better to design the system so that the respective links in the chain could support something more secure?  That way you could provide a degree of future proofing.

Clearly there would be some cost benefit analysis to weigh up but maybe many of those chain links could be made more secure to encompass a broader spectrum of use cases.   There's only so far you could take this approach.  An alternative is to pass level of assurance information - SAML supports this concept and this interesting presentation looks at the 'policy impedance' introduced where protocols that would not otherwise by combined together are joined - in this case OpenID and SAML.  

It seems to me though that the value of expressing an assurance level is poorly understood and the case is made, why bother with this when you can express this in your authorisation policy?  - A given user authenticates via an insecure mechanism therefore don't give them access rights to dataset 'A'.  That's not going to help though if your trying to apply an authorisation policy to sensitive data but your system supports an authentication scheme that is only very weakly secured.  It doesn't matter what hoops you have to go through to register for the required authorisation, the authentication link in the chain has made that a pointless exercise.

Mash My Security for MashMyData

MashMyData is underway.  This proof of concept project is exploring the provision of an online environment for scientific users to upload their data and intercompare it with environmental datasets gathered from a variety of independent data services.   These services secure access to datasets and so the management of authentication/authorisation credentials across potentially multiple hops between services provides a significant challenge.   For a project where data mash up is the primary focus, this involves a fair quantity of security related mash up too.

A recent code sprint with project partners has brought into sharp focus how we can address and implement our use case in a short space of time.   There's much to tell of the implementation details but for now this more high level overview of the use case...

A MashMyData Portal provides the user environment for data mash up.  It supports OpenID based single sign on enabling authentication within the scope of the portal but the portal itself must broker access to other services on the user's behalf.    An initial study investigated both OAuth and the classic Grid based solution of proxy certificates.   I'm keen to explore OAuth more extensively but surprisingly for me at least, the latter was easier to realise within the scope of the code sprint.  This is due in no small part to the fact that it was given something of a head start:  MashMyData leverages the existing security system developed for Earth System Grid.  In this, services support both OpenID and PKI based authentication.   The latter fits nicely with the paradigm of individual short term user certificates used in the Grid world.

At this point though it's worth taking a step back to look at how OpenID might fit in this scenario.   Some considerable time was spent in the development of the ESG security architecture on this:  you could argue the case for OpenID approach for authentication of the user by the portal at the secondary service.  By it's nature though it's unsuited in a case where the client is not a browser especially when you consider that any given OpenID Provider can impose an number of steps in its user interface and still adhere to the interface with OpenID Relying Party.   This makes it difficult to manage in our case here with a programmatic interface where there is no user interaction.

Back to the PKI based approach then.  Each ESG Identity Provider deploys a MyProxy service to enable users to obtain short term credentials but for the MashMyData portal, the user has already authenticated via OpenID.  We don't wish them to have to sign in again via MyProxy.  We can however, translate their signed in status and issue a short term certificate.  This is something that has already been employed with projects like SARoNGS and with the system devised for federated login to TeraGrid.  The diagram below shows how the MyProxy can be employed:

The user signs in at the MashMyData portal and invokes CEDA's (Centre for Environmental Data Archival) Python based WPS (OGC Web Processing Service) implementation to execute a job.  The WPS requires authentication so the portal calls the Credential Translation Service to obtain a short term certificate to represent the user and authenticate at the WPS.   [I'm leaving authorisation out of this for simplicity. - Authorisation is enforced on all services].  The translation service is in fact a MyProxy service configured with a CA.   For the purposes of the MashMyData demonstrator certain CEDA services have been configured to trust this CA.

Usually in this mode, the MyProxyCA responds to MyProxy logon requests by authenticating based on the input username/password against a given PAM service module.  The PAM might for example link to a user database.  In this case however a custom PAM accepts the users OpenID and the MyProxy service 'authenticates' against this alone and returns an End Entity Certificate back to the portal.  The portal can then use this in its request to the WPS.  The obvious question here is, given such a permissive policy what is to stop anyone requesting as many credentials as they like?!    However, only the portal needs access to this service, so access can be restricted to it alone.

Next, the job at the WPS itself needs to retrieve data from CEDA's Python based OPeNDAP service, PyDAP.   The portal pre-empts this step by priming a second MyProxy server with a delegated user credential which the WPS can then retrieve.   This second MyProxy server is configured in an alternative more conventional mode for MyProxy in which it acts as a repository for short term credentials.  The portal then, adds a new credential to this repository so that it can be available for the WPS or any other service which has been allocated retrieval rights.   In this process - a put request on the part of the portal, makes the MyProxy server create a new key pair and return a certificate signing request in return.  The Portal signs this using the user certificate previously obtained and the signed proxy is uploaded to the MyProxy server's repository.

With this in place, the WPS can execute a MyProxy logon to obtain a proxy certificate for use to authenticate with the PyDAP service.   In fact, any number of services can be configured in a chain.  Some interesting remaining issues to consider:

1. Services must be able to consume proxy certificates.  This needs special configuration, something I've discussed previously.  
2. The MyProxy delegation service has a static configuration determining which services are authorised to retrieve user proxy credentials.   On this point and the previous an OAuth based solution might provide a better alternative plus you might throw away proxy certificates altogether which would remove an SSL configuration overhead.
3. How do services discover the MyProxy service endpoint in order to know where to get delegated credentials from?  For the moment this is a static configuration but there could be a way of passing this information from the client.  Another alternative could be to add this information to the OpenID Provider's Yadis document so that it can be discovered by invoking a HTTP GET on the user's OpenID URL.  Extending the Yadis document has already been exploited with ESG but implicit is the ability for OpenID Providers to include this customisation.   This would obviously break interoperability with vanilla OpenID Providers.

The code sprint has provided a great demonstration of the flexibility of MyProxy and the ease with which something can be assembled quickly to meet the given use case.

Earth System Grid Federated Authorisation deployed

At the end of last week I deployed a PyDAP (Python implementation of OPeNDAP) instance with the latest version of the Python ESG security implementation.  This brings into play here the last major pieces in the federated security solution for Earth System Grid Federation.   I've talked before about authentication and support for both OpenID and PKI based (MyProxy) single sign on for ESG.   This latest deployment completes the picture with the authorisation mechanism.

The authorisation architecture follows the familiar PEP - PDP paradigm where in our case, a particular service is secured by a Policy Enforcement Point which itself refers authorisation decisions to a Policy Decision Point.  The PDP runs as part of an independent authorisation service.  This is shown below.  A HTTP based client, in this case a NetCDF based OPeNDAP client makes a request to the PyDAP service.  At the server, an authorisation filter (PEP) intercepts requests to the underlying PyDAP application.  It makes authorisation decision queries over a SAML interface and enforces these allowing or preventing access to the requested URL.  (Nb.  authentication components are left out for simplicity.  See this posting for details).

In the above, both PyDAP application and Authorisation service reside within the same organisation so where is the federated part of all this?  Putting that aside for a moment, the standard SAML interface between authorisation filter and authorisation service mean I can interchange different applications and authorisation services and implementations.  For example, on the left replace PyDAP with a THREDDS Data Server with ESG servlet authorisation filter, or keep the PyDAP service but secure it with the alternative Authorisation Service packaged with the Java ESG Gateway application.

Returning to the question of the federated aspect, this comes into play with PCMDI's Attribute Service.  PCMDI have an overall responsibility  across the federation for management and allocation of CMIP5 access roles (attributes) to registered users.   Consider a request to the PyDAP service: the authorisation filter protecting PyDAP can push user attributes to the authorisation service but the authorisation service can also pull attributes from outside.   If the policy determines that CMIP5 access is required, PCMDI's Attribute Service is queried to check that the user has the required CMIP5 attribute(s).  These attributes are pulled into the request context for the PDP to process and make a decision.   Following this architecture then has the consequence that PCMDI maintain control over the CMIP5 attribute.   They can add or withdraw any users enrolement and this will immediately take affect across the federation.

At this point the contents of the Authorisation Service component above needs some further explanation.   To be compliant with ESG, the component must have the outward facing interfaces shown for SAML authorisation decision and attribute query.   Within this however, I've chosen to follow a XACML based solution.   The Context Handler receives SAML based authorisation decision queries and translates them to XACML based requests and passes these to the PDP.  The PDP takes XACML policy file at start up.   The policy expresses the restrictions needed for the different datasets served from the PyDAP service.  The Policy Information Point  serves the PDP with additional user attributes when required by querying Attribute Service(s).  In this case it's PCMDI's.  The Authorisation Service is written as a Python WSGI application as part of NERC DataGrid Security.   The XACML components use the Python XACML implementation ndg_xacml.  I want to write more about this in a future post.

Taking a step back then and looking from a user perspective, I can go to the PCMDI Gateway, sign in with an OpenID from any of the trusted IdPs in the federation, register for the CMIP5 access attribute and then potentially go to any site in the federation where CMIP5 data is served and access it.