Kerberos & load-balanced OpenSSO – GSS Channel binding exceptions

Recently I’ve been working with a client to build a federated SSO system. One of the requirements was for internal employees to have seamless access using Windows’ Kerberos. This isn’t anything novel, and is something I’ve worked on for a number of organisations – though not for a while. However we came unstuck, with multiple OpenSSO servers behind a load balancer and SSL termination there rather than the servers themselves. It seems that Microsoft have done something entirely reasonable and enhanced the security of their Kerberos implementation, enabling ‘channel binding‘, wherein the requests are bound both to the Service Principal Name of the server requested by the client, and also to the SSL transport.

This breaks when a request arrives through a load balancer, since the underlying hostname doesn’t match that of the client browser request (the load balancer DNS name), and thus the AD domain controller rejects the token. Microsoft made the change enabling this ability in August 2009, in Security Advisory 973811 and then progressively enabled this for clients and servers of theirs, including Internet Explorer.

When channel binding isn’t requested by a server (in this case the OpenSSO servers), in theory it can be ignored, but currently available versions of Java don’t ignore it, instead passing it on to the AD domain controller, the result of which is a GSS Exception in the OpenSSO logs when using Internet Explorer on the client workstation. Firefox isn’t affected as it doesn’t request channel binding.

There are various workarounds which might be applicable to your situation:

If you’re looking to upgrade Java, this fix is available in release candidates of Java 7. It may be available in Java 6u19, but not in the currently release Java 6u18 or prior, unless you’re paying for Java for Business – the fix is in 6u17-rev-b06.

Hopefully this post might prove useful to someone – it took us some time to find the cause of the problem, and the resolution.

Watching my PII

For a while I’ve been thinking about how personal identity data (often called Personally Identifiable Information, or PII) is managed – both as a consumer, and from the perspective of service providers. I’ve been following along with the work being done  by (amongst others) Microsoft, Google and the Kantara Initiative UMA WG, and it seems inevitable that over the next year or so the landscape will have the scope to evolve dramatically; I say ‘have the scope’ because I wonder what this will actually mean from a consumer’s point of view.

The internet landscape of the ‘average Bob’ consumer user has changed significantly over the past year or two, resulting in not only an explosion of logins and of PII scattered everywhere, but of services that allow (or require) this data to be shared from site to site. Bob might well have logins to various sites for online account management (banks, utilities, etc), each of which will hold local copies of his PII (address, DOB, etc), but he also now has a Facebook profile, a Flickr account, and perhaps shares his travel through Dopplr and his location through Google Latitude, and allows his friends to see his data in some or all of these services.

What I want

Because I’m conscious of my PII spreading out over the internet, and of the hassles of managing it all in a secure manner, I’d like a service along the lines of that described by Mark Dixon here to manage it all; though as I commented on his post, I’d like something a bit more outward-facing. My ideal identity service would contain:

  1. Credential Vault: Consolidate credentials into one identity (‘me’), which lets me authenticate to services as appropriate. This should be a standard federated identity (an OpenID, InfoCard or whatever) where it can be, but it should also act as a LastPass-style credential vault where the service provider doesn’t support new-fangled federation. This credential store should be cloud-based, but locally cached, and optionally integrated with my OS (for strong auth via smart card, biometric, etc). The credential actually exposed to the end service will vary (I might want to be totally anonymous, or at least pseudonymous – not traceable from one service to the next), so they don’t necessarily need my strongly authenticated, full-on identity, and this is separate to my level of authentication to the broker (which is by necessity always equal, or stronger).
  2. Attribute Store / Persona Editor, with Assurance: Collect all my PII, and provide an easy way for me to group this into personae (my personalities, if you will) and present this to SPs.  Services should be able to specify that they need a level of assurance, and that the various attributes I provide are true – and my identity store should be able to keep this and present it when needed. As an example, I might just present a name (it might not be real) to a web forum, but my real address, verified by an independent body, when applying for a new credit card.
  3. Auditing and Updating Service: Beyond providing PII to sites, I want to be able to look back and find out who I gave it to. Today, I have no idea how many sites have my addresses (email or physical) – probably thousands over time. I’d like to see a log of this; moreover I’d like to be able to revoke that data from the providers, or force them to update their cache of it from my store when it changes. Furthermore, I want to know where else my data has gone – a list of which of my Facebook friends has synced my contact details to their mobile, perhaps. Ideally I should be able to set terms on registration of what each service can do with my data – this is more of a contractual, rather than technical, assertion.
  4. Sharing and translation: For site-to-site sharing of my data (Dopplr updating my Facebook, for example), OAuth describes how permission can be granted at a service-to-service level, but my Identity Store should be a broker in the middle so I can make decisions in one place. By sitting in the middle, this broker could offer additional services, translating data into a shareable format where a point-to-point service doesn’t already work.

I’d probably be prepared to pay for this, or see it as a value-add service from someone I already have a relationship with, as long as I trusted them with all this data.

What Bob wants

Bob, our ‘average internet user’, doesn’t really understand security. He’s the guy whose PC you have to fix when you go to visit, who has 15 browser toolbars from assorted malware running, and who loves to throw sheep at you on Facebook. He isn’t curious about why all those quizzes exist, and on a quiet Friday night wonders if that Viagra email might actually be a good deal.

He’s got online banking, GMail, Facebook and MSN Messenger. They all use his name (or a variant of) for the login name, and every password is the same, but it’s 8 characters and has a number in it – because his work IT policy says so, and that password is the same too.

Bob doesn’t think about where his PII is going, nor about who has it – at least until he moves house and has to tell dozens of companies – and gets a bailiffs letter because he missed one off the list and bills get sent to his old house. He’d likely be pretty confused with the concept of the identity service I’ve described.

What the services want

Service Providers (like my bank, Facebook, or even government) want me and Bob to use their services. They want to capture enough PII from me to provide that service without scaring me off (because the service is insecure, or they’re taking too much PII) or scaring Bob off (because signup is hard and confusing), in the cheapest way possible. They want users to be ‘sticky’ to their services, locking me in as much as they can so I don’t leave for a competitor. And if they’re less than scrupulous, they can sell all my juicy PII to ad companies.

The attributes actually needed by the service provider, and how sure they need to be that the attribute is trusted, varies according to the service. Twitter doesn’t care that I’m me – unless I’m a celebrity – but the government wants to be pretty sure I’m who I say I am when issuing me a passport.

There aren’t too many standalone Identity Providers, and no ‘Identity Store’ brokers in the way I describe that I’m aware of. The best we have today are things like OpenID and OAuth. These allow me to use the credentials from one service provider to access others, or to set up point-to-point data sharing, but these are far from perfect… Google is of course keen for me to use my Google login to access services like Plaxo or Facebook – but they wouldn’t let me use a credential from these sites to get into all my Google services. This is done to assert the Google brand, and to keep me using their services.

Will we meet in the middle?

The various great technical minds in the identity world will no doubt come up with excellent solutions to a lot of this, but I don’t think the technology is the real challenge; instead, it’s the fact that the bulk of internet users are like Bob.

Service providers are generally not independent enough to build a complete service like this, and for it to be truly trusted, and there isn’t a business case for a standalone identity provider because most people are like Bob, and wouldn’t pay for an identity service.

It’s not all doom and gloom, however. The fact I can use my Facebook, Twitter, Google or Windows Live login to log into multiple sites is a step forward; indeed I even think the ‘NASCAR problem‘ is a good thing, because it’s forcing people to think of elegant ways to move forward. This will over time

I’m not sure there’ll ever be a business case for completely standalone identity providers, but would imagine decent consumer-grade services will evolve out of services like Verisign’s Personal Identity Portal, or equivalents from people who already store lots of your PII (credit agencies, governments, banks etc) when they spot the consumer value in doing so. These will inevitably be multi-tiered services, offering Bob something nice and simple, yet offering me a (perhaps paid-for) more complex service.

As someone working in the identity field, I figure the best way to drive these things forward is to encourage all the Bobs I know to be more aware of their PII and where it goes – if enough of them start to ask questions, the services to support them will fall into place.

SAML Federation for dummies

A couple of times recently I’ve had to explain SAML-based federation to people whose areas of expertise lie outside identity and security. After repeatedly drawing things in different ways on a whiteboard, I found myself working towards a real-world analogy.

It’s a bit tortured, and not exactly representative of the inner workings of SAML, but it gives the basics. For a real, technical explanation, the Wikipedia page gives a good outline, and hardcore nerds can read more at saml.xml.org… But if you’re interested in reading those, you’re probably not the right audience for this post anyway.

The basics

So, we’re trying to achieve federated SSO – that is, I’m a user at Company X, and I’m trying to access resources at Company Y. As the user, I don’t want a new set of credentials to manage at Company Y, and Company Y doesn’t want to have to deal with joiner/leaver for me. SAML allows us to solve this problem fairly easily – indeed in the case of some service providers (Salesforce and Google Apps as an example), this is trivial out-of-the box functionality for some SSO systems.

SAML federation occurs through a series of interactions between the two parties, after first establishing trust between them. So, on to…

The analogy

Imagine I’m a consultant (I am, so it’s easy for me), and I’m going to be working on a client site for a while. We’re going to look at my interactions with my own employer (my identity provider) and that of the client, whose resources I’ll be using (the service provider).

Establishing trust

Clearly, I can’t just turn up unanounced at the client’s site. There’ll be a series of meetings, swapping of business cards, probably some lunch… And then a contract will be signed. This contract will determine the length of the work order, and we’ll probably sign NDAs, and perhaps we’ll be given details of security behaviour (what to do on the first day, etc). The client will conduct due diligence, making sure (s)he knows our company, checks references and so on.

What we’ve done here is established trust between the two entities. They know who each other is, have contractual agreements on information sharing, and some basic protocol information.

Swapping tokens – authentication

So, now that we’ve arranged the work, on Monday morning I’ll turn up at the client’s office. Of course, the guy at the security desk has never heard of me. So firstly he asks me for some recognised ID, and I show him my passport. So now he knows I’m who I say I am – one might say I’ve used a standard protocol and token. But he doesn’t know that I really work for my employer, so a couple of things might happen. He could check in his computer system and call the security team at my employer, or call someone in his own organisation who’s already done this.

He’s now established I’m who I said I was, and that I belong in his building, he gives me a security pass for the building. It’s a temporary pass, obviously. It might be valid for the whole duration of the work order, or a shorter period. If the contract is a long one, he might want to periodically call up my employer to make sure I haven’t been fired – but probably not every day.

So, I’m authenticated at my employer with a token (my security badge). But the client doesn’t understand this so a shared token standard is used to convey this information to the client – my passport. On validating the token, the client needs to check that I belong to the partner and I’m not just a random, so they call up and check, in the same way SAML back-channel validation can occur. Once validated, I’m given a session token with the client/provider, which has a local expiration, and a periodic check against the partner.

Authorisation

The building pass he’s given me lets me into certain parts of the client building, based on the work I’m doing for them (as agreed with my employer). This compares to the pass I’ve got from my employer, which restricts me to access based on the job I do when I’m back at base – but the two cards are completely unrelated and disconnected.

Here we’re highlighting that my level of access on either side of the partnership are disconnected. My employer has agreed the work package with them, so they know what access to give me in their building based on that role. This is of course related to my role in my own office – but the access level given here is completely different.

…For dummies

So, that’s a high level explanation of how federation occurs, particularly with regard to SAML. I’ve found it a useful simplification for people who have no comprehension of how this stuff works – obviously it breaks down if you look more carefully! If you read this and can think of improvements, let me know.

Update: I had some debate with @paulmadsen regarding the ‘passport’ part of this. It doesn’t really work in the analogy – I was trying to convey the idea of the SAML token being something generated to a common standard, that both parties understand, and that’s not the same as the internal auth token necessarily. A passport is wrong since anyone can read your passport in the real world, but with SAML only the two endpoints can read it.

User-centricity

Last week, I gave a talk at IDM 2009 entitled ‘Privacy and Data Minimisation with Improved Business Returns’. A bit of a mouthful and the result of title-decision-by-committee, but good subject matter!

The main message of the talk was that by focusing on flows of data (particularly, but not limited to identity data) and the user owning that data, you can improve security, your user/customer experience and drive improved financial returns. The slides for the talk with accompanying notes should hopefully be up on our website shortly.

The topic is one that’s gaining focus as organisations shift focus from using IAM solutions to manage risk/compliance and regulatory requirements to more intelligent, business-focused solutions. In discussions with clients, there’s an eagerness to bring IAM out of the ‘back room’ and integrate it more tightly with CRM and BI tools – but also to empower users.

This is seen in internet properties from Google and Yahoo (amongst others), giving the user the ability to share logins, contacts, location and other personal data. Whilst this is great for simplifying things for a user across a number of sites, the key is to empower the user to decide which data is shared, and where. Both in an enterprise context and on the internet, it becomes a challenge to present this to the user in a friendly way, highlighting which data is owned by the user and which by the ‘other party’ in each context. This challenge looks to be where my focus is going to be for the next few weeks, at least.

OASIS – Identity Management 2009

On 29/30th September, I went to the OASIS Identity Management 2009 forum, the theme of which was ‘Transparent Government: Risks, Rewards and Repercussions’. It was my first time at an OASIS event, and befitting the organisation and the location (it was hosted at NIST), the content was pretty in-depth and technical.

I’d really hoped to convert my scrawled notes into a series of posts on the topics covered, but time has escaped me and so I thought I’d at least post some of the notes I’d taken in rough form so that they didn’t get completely lost… So here are the notes from Day 1. If I get time, I’ll come back and post on some of these topics in more detail!

(There are also plenty of notes from other folks on the event’s Twitter stream, #idm09.)

OASIS IDM 2009 – Day 1

Session 1 – Use of Open Identity Technology In Government

– Leverage existing, open identities for government applications
— New government 2.0 initiative
— Using OpenID / InfoCard vetted providers
— 10 providers -> Can choose which provider / id (Google vs Equifax, for example)

GSA defining ‘profiles’ – sets of standards at specific versions, guaranteed compatible
— Also ‘levels of assurance’ – criteria for various strengths/token types, according to risk/impact of incident
— Not building again, mapping publicly available identities against government assurance levels

–New concept of open trust framework to certify IdPs
— Jointly presented by OpenID, InfoCard foundations
— Outreach to OpenID, InfoCard, InCommon, Liberty and Kantara

–> Open Trust Framework
— Doesn’t presume any existing circles of trust (vs SAML)
— User controlled identity management
— Open, reusable

Anyone can become an IdP, but need to be vetted.

ICAM profiles force private sector IdPs to be precise, to meet the government-specific requirements
It’s a win for the government, industry and the public:

– Govt doesn’t build in a silo
– Industry gets tighter specs to focus on, and drive wider adoption
– Users get reduced numbers of identities, at government levels of assurance

– No verification of assertion attributes, just that attributes are present (e.g. email attribute not checked to be a valid email)

SAML Profile: Already exists, based on existing SAML use cases in govt.

ICAM OpenID Profile:
– Only for sites at LOA1 thus far
– Based on OpenID 2.0
– SSL enforced on all endpoints
– “Directed Identity” approach, i.e. identity appears different to each RP, so no tracking
– Other restrictions defined in profile too, to ensure appropriate security

InfoCard Profile:
– acceptable at LOAs 1-3 (maybe 4)
– Focus on the UI, digital ‘card in wallet’ – card selector in browser
– Can have varying underlying auth methods
– Only supports Managed Cards, IdP issued
– Card auth mechanisms are un/pw, X509, Kerberos, etc

— Truly user-centric would be self-managed

Don Campinella (Equifax)

Spoke about ‘persona control’ – multiple personas for a given identity
Attribute use assurance
Verification of claims

Suggested that a commercial IdP gives experience, data, scale, trust
Better fraud protection and privacy (some liability?)

Discussed at LOA1 use of pairwise unique IDs, pseudonymous: reusable unique identifier given to each RP, but can’t be traced back to the user unless the user shares attributes. Each pairwise identifier can be revoked from the RP.

Quoted that 20% of Medicare/Medicaid fraud is at the service provider, not the user, so we need to authenticate the service providers as well as consumers. This creates the need for a standalone IdP, outside of the RP.

Session 2 – Mary Ellen Callahan (CPO of DHS) & Ari Schwartz (COO – Centre for Democracy & Technology)

MEC on the baseline of govt idm tech – “It’s got to work for my mum” – what happens if something goes wrong? Not just a data breach, but how do you interact with the individual and manage the problem.

– Should have a plan, since nobody’s infallible
– Elements of redress
– Harm-based analysis
– Not just financial loss, but also reputation, etc.
– Maybe even public safety (location data, etc)

-> All about trust of government

Overall message: “Make it as secure as can be, but also plan for the worst. Have a policy to a) deal with it and b) prevent it recurring”

AS – Test of ‘user-managed identity’ is not in the user interface or the technology, but whether the user is on an equal footing with the IdP and the RP.

Session 3 – John Tolbert (Boeing)

Using XACML and ODF for Export & IP controls

Need to have resource (classification, ECCN, USML)  & subject (nationality, location, US person) attributes

For IP controls, there’s an OASIS-XACML-IPC profile.
By using XACML, there’s a simpler, quicker adoption
-> Government can push out standard policy in XACML format to be used in a central decision engine at each org
-> Facilitates quick updates, easier audit – using standardised XACML means standardised rules (though relies on accurate metadata)

Extending this to ODF document control profiles, to match the XACML-IPC profile. This gives end-to-end authorisation, not just at the point of distribution.

Gives the organisation a single set of policies / rules to manage.

Breno de Medeiros (Google)

Drivers for federated identity standards in Google are predominantly credential reuse and social graph sharing

– Social sites ask for passwords for data harvesting
– This is bad! Users are trained then to share passwords (see Linked In, Dopplr, etc)

More reputable sites are less likely to implement APIs for authorisation/delegation as an RP, since they have little to gain. To succeed, providers should give a rich authorisation/delegation API, and a good UI!

Example of Plaxo & Google – OAuth and OpenID combined, but with friendly simple UI. Google account can be used to login to Plaxo, then OAuth allows for sync of contacts.

UI: Per-attribute authorisation is difficult, every additional checkbox makes the UI more complex and prone to rejection by the user. Also noted that users expect a ‘generated’ ID to be pairwise, but a social site ID, or manually created by the user, to be a global, shared identity. Need to be careful as PII could be exposed in URLs (email address, other correlatable data)

Current UI for OpenID that hides the ID is good (‘use your Google/Facebook/Live ID to login’) but isn’t scalable. There needs to be a good browser interface (like InfoCards) for IdP discovery in a privacy-aware way.

Session 4 – SAML 2.0 in government

Karen Higa-Smith (DHS programme manager)
Anil John

Discussion around use of SAML2 for data sharing.
Authentication is already handled by the PIV smart card.

“Profile” created – this is a set of specs at particular levels along with guidelines and implementation documentation for use within government departments. It’s not a ‘standard’, since building these is slow and expensive.

Programme to manage ‘backend attribute exchange’ (BAE).
– Built a deployment profile and documentation
– Build a proof of concept BAE reference implementation, using synthetic data, to show interoperability between multiple vendor products following the BAE profile

– Idea was to document the profile but not to reinvent the wheel, instead to use commercial or free products and existing standards. Programme should allow for multiple approaches and technologies, but to ensure interoperability.
– Encouraging COTS vendors to provide out-of-box support for the US government BAE profile.

Explained two models
1- Direct Attribute Exchange
2 – Brokered Attribute Exchange

In the first case, a simple data exchange using SAML from point-to-point
In the second, smaller departments can use shared infrastructure from a larger department – but the data should be encrypted so that the shared infra provider can’t read the data. This was successfully accomplished using existing SAML standards.

– Specification of supported attributes, name identifier, encryption standards, etc are all specified within the SAML exchange.

– Also integration with the CA, so that user identities can be mapped to those on PIV cards or other certificate issuance.
– Flexible name identifiers, so that there’s no enforcement of a specific unique identifier.

Session 5 – Social Identity

Burton: Leveraging relationships & managing social identity

Discussed benefits of social identity (profiles, social graphs, etc) within the enterprise
e.g. Establishing social data in enterprise portals (skills, expertise, interests)
Leverage within blogs, wikis, forums – munge this data for display on portal -> activity feeds
Allow for ‘following’ of employees, subjects of interest

‘Facebook for enterprise’ – already have business dashboards, sales dashboards – why not a social dashboard?
Supports strategic talent, encouraging interaction, reflects generational shift towards social interactions

BUT
– problems of profile proliferation across multiple internal sites (and external)
– solve this with federation/sharing – but then problems of data leakage?

– Also automated activity stream causes sensitivity issues (e.g. posting on a gay forum, completing a sensitive deal)
– Resolve through access management, but then this risks losing serendipity. Creating a balance of access restrictions and openness is a big challenge.

-> Becomes an even bigger problem when trying to merge social graphs between internal and external tools (Facebook, Linked In)
– Breaking boundary between “work me” and “citizen me”. Is it acceptable for your boss to contact you about work issues on Facebook? Should they know about your out-of-work activities?

Roles:
– Enterprise roles are well defined, though centred around access control
– Social roles proposed, e.g. “News filter”, “wiki gardener”
–> Social ‘talent management’, mining within the enterprise?

Vendor presentations

IDology (Jodi Florence) – identity verification provider
Anakam – government to citizen verification – a sliding scale from anonymous through to vetted proof with liability
Privo (Denise Tayloe) – Parental consent for managing a child’s identity and data sharing

Laws of Identity

There’s a stereotypical image that people who work at Microsoft are insular and inward-looking. Kim Cameron is far from that. He regularly posts insightful commentary on the ‘identity metasystem’ on his blog, and is widely seen as a ‘thought leader’ in identity management, driving forward standards such as Information Cards and taking a pragmatic, standards-based approach to Microsoft’s involvement in the ecosystem.

A couple of years ago he came up with a set of Laws of Identity – embracing the ideas that users should always own their data and dictate how it’s shared, that there should be minimal disclosure, and so on. In this post, you can see links to more detailed descriptions of the laws, and a nice image summarising the laws (shown below).

I’m spending progressively more time at work thinking about public/consumer identity as well as that kept within an enterprise, and I find keeping these laws in mind ensures the delivery focus is kept in the right place.

on identity, privacy, the environment, and other assorted rants.