Tag: SAML

Linkey update w/c 18/02/2013

Alex Bilbie / / News

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.

What is SAML (and what has it go to do with OAuth) ?

Alex Bilbie / / Uncategorized

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.

OAuth 2.0 and the road to hell

Alex Bilbie / / Uncategorized

Eran Hammer who, until a few days ago, was the main editor of OAuth 2.0 has written this very damning blog post about the protocol

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

I’ve been following the working group for about a year now and there has been an awful lot of bickering and mindless discussion.

As I’ve stated already, I’ve spent the last few weeks working on a brand new library that implements the current spec (draft 30) and I do feel myself agreeing with some of his points:

  • Yes the specification mess, I’ve highlighted and sticky noted the printed document to death and the flow between different sections is really bad
  • Some new features such as refresh tokens are overly complicated and don’t benefit the protocol, and it means clients now have to maintain access token state added to complexity
  • Just reading the spec you can tell how much it has been influenced enterprise – many features are very open ended so that you bolt OAuth onto something else (or something else onto OAuth)
  • Bearer tokens over SSL/TLS by themselves are bad and I think signatures need to come back
    • Basically if I steal someone’s access token I can use that wily nilly, however with signatures the entire request is signed with the client’s secret key so unless the secret key is leaked you can’t just use access tokens by themselves

I disagree however that the protocol (in it’s current state) is complicated, they’ve done great work at making it a 3 (or 4) legged protocol to just 2 legs and everyone agrees that bit of the protocol has been done well.

In terms of his suggestion that alternatives to OAuth that are outside the reach of the IETF might crop up I’m quite interested in this and if something crops up I’ll stick my nose in, and if one doesn’t then I’d be interested in having a go in writing one myself as an output of Linkey.

In terms of the extension documents (which include the assertions (SAML) extension, i don’t know enough about SAML to make any sort of informed opinion about this, however I’ve also still yet to see any public implementation of it.

What is Microsoft Forefront Unified Access Gateway (UAG)?

Alex Bilbie / / Overview

Microsoft Forefront Unified Access Gateway (UAG) is a piece of server side software which provides secure access to corporate networks, systems and applications. It incorporates a number of different access technologies including VPN, HTTP reverse proxies and the Microsoft-developed technologies DirectAccess and Remote Desktop Services. Remote clients can access these corporate resources through a special web site that is hosted on an IIS server which is bound to the UAG software.

UAG includes built integrations for Microsoft Exchange Server (2003, 2007 and 2010), SharePoint Server (2003, 2007 and 2010), Remote Desktop Services and Citrix Presentational Services. It also includes a technology called SSL-VPN which allows for authentication integration with most 3rd party and custom software.

UAG can use a number of different authentication sources including Active Directory, LDAP, RADIUS and SecurID. Finally it can also “speak” SAML and ADFS.

Microsoft identifies a number of benefits of using UAG:

Forefront Unified Access Gateway (UAG) is designed to provide secure remote access in a way that extends application intelligence, security and control, and ease of use. Key benefits include:

Anywhere Access

Forefront UAG makes it easier to deliver secure remote access to your applications and resources, and improve employee and partner productivity, by combining an intelligent access policy engine with a variety of connectivity options including SSL VPN and Direct Access. Forefront UAG:

Empowers employees, partners, and vendors to be productive from virtually any device or location through integrated SSL VPN capabilities.
Delivers simple and secure access optimised for applications such as SharePoint, Exchange, and Dynamics CRM.
Extends networking connectivity with Windows Direct Access to existing infrastructure and legacy applications.

Integrated Security

Forefront UAG improves the security in remote access scenarios by enforcing granular access controls and policies that are tailored to the applications being published, the identity of the user, and the health status of the device being used. Forefront UAG further improves security by enabling strong authentication to applications and mitigating the risks of downloaded data from unmanaged devices. Forefront UAG:

Protects IT assets through fine-grained and built-in policies that provide access to sensitive data based on identity and endpoint health.
Easily integrates with Active Directory and enables a variety of strong authentication methods.
Limits exposure and prevent data leakage to unmanaged endpoints.

Simplified Management

Forefront UAG offers a single platform through which to deliver and manage remote access. With built in policies and configurations for common applications and devices, you can gain more control, more efficient management, greater visibility, and lower total cost of ownership. Forefront UAG:

Consolidates remote access infrastructure and management.
Simplifies deployment and ongoing tasks through wizards and built-in policies.
Reduces support costs by delivering a simplified connectivity experience for users.

Source: http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx

How UAG can help us

At the university we have a number of existing web based applications which will benefit from having UAG integration.

We currently have SharePoint and Exchange 2003 installations (which will soon be upgraded to 2010) which UAG can natively integrate with.

We use Blackboard Learn as our LMS and Zendesk as our support desk software, both of which have can use SAML for single sign on.

We are also looking into potentially using UAG as the access point for Windows 7 thin client access.

How can UAG work with OAuth?

As UAG can use SAML to communicate with services it means that we can use the OAuth 2.0 assertions specification to create a translation framework between SAML assertions and OAuth tokens. This will extend some of the work that we’ve originally done on our OAuth server and the updated code will be published.

One of the outcomes of this project will be a case study (with open source code examples) on how UAG and an OAuth server can work together (though because we don’t know how this may work at the moment it could be that it turns out they can’t work together…) and on this blog we will document our experience.

Linkey, Chapter One

Alex Bilbie / / Nutshell

It’s 9am on Monday 25th June 2012 and the Linkey project is officially kicking off.

What is Linkey

Linkey is a JISC funded research project under the Access and Identity Management programme. It will run from June 2012 to May 2013.

The project will provide a detailed case study of the use of OAuth as an authorisation protocol here at the University of Lincoln. Working closely with the university Library, we will examine how the OAuth 2.0 specification can be integrated into a ‘single sign on’ environment alongside Microsoft’s Unified Access Gateway.

Our intention is to show how OAuth 2.0 can be used as part of an access and identity environment in higher education that improves the student experience by:

  1. A consistent and user centric sign-­in experience.
  2. A richer exchange of user information between applications.
  3. Easier development and implementation of new products.

Why?

A recent review of the university’s library systems and services indicated that we had around 10 core applications which provide access to over 150 other resources, all of which have different methods of authenticating users – some used LDAP to authenticate users (and so users use their network username and password) and others had their own database of users (which require a different passwords – and in some cases usernames – and every single one of these flows have a different sign in experience; some are web based with various designs, others are desktop based with a mixture of custom sign-in windows and Microsoft sign-in screens. Over 80% of user queries sent to the Library’s support email address around about problems accessing resources.

Outside of the library there are over 100 other systems and services that have visibility in the business processes across the university which also authenticate in a number of different ways.

All of these different authentication flows lead to a very inconsistent user experience and consistently for the last few years this has been highlighted in numerous student surveys.

Who?

I (Alex Bilbie) will be undertaking the majority of the work on the project. This will include researching technological solutions, engaging with end users, developing the open source OAuth 2.0 PHP server and working on the final implementation.

The principal user on the project will be Dave Masterson, Head of Electronic Library Services, who has been charged with improving the usability of our Library’s online services.

The project manager for the project will be Joss Winn, Senior Lecturer in CERD and co-ordinator of the LNCD group.

Tim Simmonds, Online Services Team Manager, will assume management and oversight of the technical implementation of both OAuth and UAG.

When?

The high level work plan is a below:

Month 1 2 3 4 5 6 7 8 9 10 11 12
Initiate project X
Community Engagement X X X X X X X X X X X X
Gather user requirements X X X X X X X X X X
Evaluate available technologies and options X X X X
Design Solution X X X
Technical development and implementation X X X X X X X
Write case study X X X X X X X X X X X
Write/submit conference paper X X X X X X
OAuth workshop  X
Project close X

You can follow the day to day activity on our Pivotal Tracker project page.

Outcomes

The anticipated outcomes of the project are:

  1. A case study of our implementation of OAuth 2.0 together with Microsoft’s UAG product. We will provide draft sections of the final case study in 12 monthly blog posts, allowing for early peer-review.
  2. Continued development of our open source OAuth 2.0 server (based on my server code), including an implementation of the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification and other relevant extensions to the main standard. We aim to produce a ‘drop in’ solution for OAuth 2.0, in a similar way that the SimpleSAMLphp project supports SAML implementations.
  3. A public workshop on the use of OAuth 2.0 in Further and Higher Education.
  4. A conference/journal paper, based on our case study.
  5. Expertise in the implementation of an institution-wide infrastructure for AIM.