Posts tagged Identity management

Last week I was in San Francisco for the 16th Internet Identity Workshop to disseminate the Linkey project and engage with those in the online identity communities.

The event was sponsored by many big names including Microsoft, Ping Identity, Google, Janrain, Yubico, Cisco, OneID and NetIQ. In attendance were employees from all of the sponsor companies as well as delegates ranging from freelance developers to information compliance officers at big companies to authors of many Internet specifications and protocols such as OpenID, OAuth and SAML. About half of hundred or so delegates had travelled from outside North America including about ten of us from Europe. Surprisingly I was the only delegate representing an educational institution.

The conference itself was un-conference style – i.e. each morning delegates would volunteer sessions which were then slotted into the timetable. A full list of all of the sessions can be found here. The sessions people put forward tended to either be very technical or were higher level, almost philosophical discussions.

Here is a list of sessions I attended (session notes can be found here):

  • T1G: Native Apps – SSO
  • T2B: Strong 2-Factor For All – Google and FIDO Alliance
  • T3C: The OAuth Complicit Flow
  • T4G: Identity Federation: Failed Consumer Experiences and WHat We Can Do About It
  • W1H: OAUTH Client Registration
  • W3B: OAuth 2 Bootstrapping from device to browser (technical)
  • W4B: Google’s Auth goals for the next 5 years
  • Google are strongly committed to OAuth!!!!
  • W5I: OAuth 2 Federation – RS trust external AS
  • TH2E: Practical DATA PROTECTION – Avoidance? EU and US ?
  • TH3A: RESPECT CONNECT “Facebook Connect for Personal Clouds” OR “Social Login that Doesn’t Suck”
  • TH4F: Self-Hosted Personal Clouds (FreedomBox and Raspberry PI)

The two main overarching topics throughout the event were “privacy” and “data ownership”. There were also a number of sessions about security, with one session that I attended by Google about 2-factor authentication resulting in quite heated discussion (namely because the work Google and the FIDO Alliance is not public and there is a high fee for membership).

Another interesting session was called “The OAuth Complicit Flow” (notes here) which had the premise of “what if the an OAuth authorisation server asked you to agree to “allow this application to connect to your account and murder someone” and there was no deny button. The discussion dealt with the issue of some applications asking for too many permissions, users not reading through the approve screens (similar to how users just accept EULA agreements) and applications refusing to let users access them unless they agree to allowing the application share stuff on their Facebook wall, or see the user’s friend list. Potential solutions that came out of this discussion was “reactive” permission requests as opposed to “preemptive” permissions – similar to how some iOS apps don’t ask for permission to send push notifications unless you click a button in the settings for that app.

I got the opportunity to have a chat with Mike Jones from Microsoft who has been leading much of the work on the OAuth 2.0 and OpenID Connect specifications. He answered a few questions I had about edge cases in implementations and he was interested in the PHP libraries I’d developed as part of the project.

I didn’t have the opportunity to talk at length about Linkey but in all the sessions I attended I tried to take part and I had some really interesting discussions with people about some of work that we’re doing in HE around open data and open APIs (including work on OAuth) and I was able to talk about some of the issues we faced with implementing OAuth in enterprise environments (because of incompatibility and lack of understanding compared to SAML).

I feel that the conference was definitely worth attending and I would encourage JISC and other interested parties in the education sectors to try and attend the next Internet Identity Workshop as I left feeling that we’re dealing with some very similar problems that even the very large organisations present such as Oracle are dealing with.

It’s been a long time since I last gave an update on Linkey so I’ll try to summarise what has happening recently.

In late Janaury, Chris Brown the manager for the Access and Identity Management (AIM) programme visited us here in Lincoln. We spent a few hours looking over the case study that I’ve been working on and Joss and I discussed how the work we’re doing on Linkey fits into the eco-system that LNCD have developed. A number of actions came out of the meeting:

  1. Get in touch with a number of contacts that Chris has at Kent and Newcastle to discuss a number of AIM related projects and what we can learn from them.
  2. Get in touch with contacts at Warwick University who have a number of APIs and tools that are secured with OAuth 1.0. If possible I would like to include their work in the case study.
  3. Speak to JISC InfoNet to see if a toolkit could be created out of the case study.

I’ve spent a few months trying to find an appropriate conference to go to so that I can engage with the AIM community and discuss the project and it’s outputs. After much searching for the right conference I’m happy to say that I’m going to be going to the 16th Internet Identity Workshop in Mountain View, California. Being in the heart of Silicon Valley I’m really looking forward to meeting developers and evangelists from companies such as Google, Facebook and Microsoft, all of whom are trying to be “our” online identity provider.

As part of my research for the case study I have been looking into the many use-cases of OAuth. Recently I’ve been experimenting with securing an RDF SPARQL server to only respond with triples that an access token (sent in a HTTP header) can access. I will blog about this later once I’ve got a bit further with it.

Since January I’ve been working on the OAuth code which has had some great contributions from some guys from the US. It is now finished and running in production in several places (more on this in another blog post). In addition, now that the code is complete I can start developing a plugin for the SAML bearer grant.

Finally, the Linkey project will officially finish on the 25th June.

One of the outputs of the Linkey project is an open source PHP library that implements the SAML bearer assertion extension (draft 13 at time of writing) to the OAuth 2.0 specification.

But what is SAML?

SAML, or Security Assertion Markup Language, is an XML-based framework that allows identity and security information to be shared across security domains – for example between two websites.

Information is exchanged through the concept of assertion tokens, which are XML documents that state facts about the assertion’s subject. For example, a SAML assertion about me might look like:

<saml:Response ID="_257f9d9e9fa14962c0803903a6ccad931245264310738" IssueInstant="2012-09-03T18:45:10Z" Version="2.0">

    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">

https://www.lincoln.ac.uk

    </saml:Issuer>

    <saml:Status>
        <saml:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml:Status>

    <saml:Assertion ID="_3c39bc0fe7b13769cab2f6f45eba801b1245264310738" IssueInstant="2012-09-03T18:45:10Z" Version="2.0">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">

https://www.lincoln.ac.uk

    </saml:Issuer>

    <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
            abilbie@lincoln.ac.uk
        </saml:NameID>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml:SubjectConfirmationData NotOnOrAfter="2012-09-03T18:50:10Z" Recipient="https://sso.lincoln.ac.uk"/>
        </saml:SubjectConfirmation>
    </saml:Subject>

    <saml:Conditions NotBefore="2012-09-03T18:45:10Z" NotOnOrAfter="2012-09-03T18:50:10Z">
        <saml:AudienceRestriction>
            <saml:Audience>https://sso.lincoln.ac.uk</saml:Audience>
        </saml:AudienceRestriction>
    </saml:Conditions>

    <saml:AuthnStatement AuthnInstant="2012-09-03T18:45:10Z">
        <saml:AuthnContext>
            <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
        </saml:AuthnContext>
    </saml:AuthnStatement>

    <saml:AttributeStatement>

        <saml:Attribute Name="name">
            <saml:AttributeValue xsi:type="xs:anyType">Alex Bilbie</saml:AttributeValue>
        </saml:Attribute>

        <saml:Attribute Name="network_id">
            <saml:AttributeValue xsi:type="xs:anyType">abilbie</saml:AttributeValue>
        </saml:Attribute>

        <saml:Attribute Name="division">
            <saml:AttributeValue xsi:type="xs:anyType">ICT Services</saml:AttributeValue>
        </saml:Attribute>

        <saml:Attribute Name="staff_directory_url">
            <saml:AttributeValue xsi:type="xs:anyType">http://staff.lncd.org/abilbie</saml:AttributeValue>
        </saml:Attribute>

    </saml:AttributeStatement>
    </saml:Assertion>
</saml:Response>

This assertion here states that my name is Alex Bilbie, my network ID is abilbie, my division is ICT Services and that my staff directory page is http://staff.lncd.org/abilbie.

Generally the assertion will be provided by an “identity provider” (a.k.a an IDP) and consumed by a “service provider” (a.ka. a SDP).

SAML is often used in single sign on environments. Let’s consider a student trying to sign in to the student union website:

  1. The student (the user) would visit student union website (the SDP)
  2. The SDP would realise the user isn’t yet signed in and so redirects the user to the single sign on endpoint (the IDP)
  3. The user authenticates with the IDP
  4. The IDP redirects the user back to the SDP with the assertion (by using a HTTP POST)
  5. The SDP consumes the assertion, validates it and signs the user in

How does SAML compare to OAuth?

For reference, this is how OAuth is used in a single sign on environment:

  1. The student (the user) would visit student union website (the client)
  2. The client would realise the user isn’t yet signed in and so redirects the user to the single sign on endpoint (the authentication server)
  3. The user authenticates with the authentication server
  4. The user grants the client access to their private data
  5. The authentication server redirects the user back to the client with an authorisation code in the URL
  6. The client exchanges the authorisation code for an access token with the authentication server by itself authenticating
  7. The client then sends a request to the resource server to request the user’s private data. The access token represents permission granted by the user for the client to act on their behalf.

Now the OAuth flow looks longer it contains one important stage which is a requirement of the specification, specifically step 4 which is where the user is explicitly asked if they want to allow the client to access their data and also what data will be accessed. You could emulate this in the SAML flow but I think the upfront honesty so to speak in the OAuth flow is a huge advantage for users. Also most OAuth authentication servers allow users to revoke access to clients as well (i.e. their access token for that client is destroyed which immediately cuts access).

In both flows, the client/SDP itself is verified. In SAML this is done through certificate exchanges, in OAuth the client’s ID is validated at step 3 and step 6.

How does the assertion extension work?

Looking at the OAuth sign-in flow above, at step 6 the client exchanges the authorisation code for an access token. There are a number of ways this can step can actually work and each different method is called an authorisation grant type. The grant described above (and the grant is the generally used in most OAuth implementations) is the authorization_code grant.

The assertion extension defines a new authorisation grant type of urn:ietf:params:oauth:client-assertion-type:saml2-bearer. There is also another parameter called client_assertion which is a base64 encoded representation of the XML assertion. The client/SDP’s own credentials are in the assertion instead of being sent as client_id and client_secret parameters as in the authorisation code grant.

An example request would look like:

POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

The specification includes a number of elements that must be included the assertion in order to provide the authorisation server with all the details it needs about the request.

As I understand it there is also an optional scope parameter that can be passed in the request any scopes that the client/SDP requires.