Tag Archives: identity

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.

Busy week ahead

So we’re approaching the first major release of my identity management project. It’s taken a while to get us close to the release, mostly through no fault of our own. Given it’s taken us so long, unsurprisingly the ground has moved underneath us.

There’s a new release of Sun Identity Manager just out, version 8.1. This close to a go-live I wouldn’t normally contemplate upgrading, but it seems to have a good set of features worth investigating – not least better SiteMinder integration and open source identity connectors.

A nice touch, whilst terribly dull, is a blog that features updates/changes to the documentation, so you can get notified via RSS of significant updates. Their competitors could learn a lot from this sort of open way of working.

Mining for your rights

Whether in the guise of increasing regulatory pressure, or through a credit-crunch-driven round of redundancies, most organisations of more than a handful of people need to verify the IT access their employees have, comparing this regularly to the rights they should have.

Both in my own experience and through stories of others, it seems most large organisations are woefully bad at doing this – most often conducting adhoc manual reviews, orchestrated by an overworked IT Security team. These are almost always achieved through mailing Excel spreadsheets, or people wandering the office with printouts… “Are you the owner of this system, and if so, what does it do?”

There are far better ways of doing this – both as a one-off, and as a regular exercise.

First step – People

Firstly, you need a good source of people data – ideally your HR system or some kind of directory containing names, job titles, locations and line managers of your employees. It’s important to be able to trust this hierarchy – there’s little point worrying about access rights if you’re not sure whether someone’s still an employee, or who they work for.

Current access rights

Once you know who all your people are, who their managers are and what job they do, you need to determine the access they have.

If you’ve got a provisioning system, great – this will already have a store of the rights in most of your key systems. If not, or for systems beyond the scope of your provisioning tool, you’ll need to capture the user access rights.

For critical applications, you might be forced to report on this sort of thing anyway, but if not, get into the habit of capturing simple files of users and group memberships.

Validation – the challenge

So you’ve now got an employee hierarchy and a series of application rights. To validate, it’s just a matter of checking with a given user and his/her manager that the access is what they need and no more, right? That’s a great theory, but most business managers have no idea what group TRD47 does or why you need to be in it or the hundreds of others that you’re in.

Here’s where that ‘better way of doing things’ comes in – most identity & access vendors now have products for role mining & certification.

Let’s take a big warehouse and into it pour all those lists we collected earlier. Next, we’ll take the following steps:

  • Get line managers to confirm their direct reports
  • Get system owners to describe each access group for their application

From here, we can run some pattern matching giving output like these:

  • All employees get a mail account and Windows login
  • All IT staff get admin rights to their workstation
  • All traders get access to the trading system
  • HR get access to the HR system

Starting with really broad definitions that cover as many people as possible, we gradually narrow down on individual teams, defining the rights they have into business roles. When we’re happy, we can start to validate these roles, having the IT organisation confirm each permission group.

This leaves business managers just to confirm that employees have one of these ‘friendly’ roles.

The second time

Once you’ve captured these role definitions and validated them (and their exception cases), it’s relatively easy to maintain this and conduct regular audits.

Whenever a new system or group is created, this gets captured. If you release a new application, you’re most likely aiming it at a set of users, and this should already have been defined as a role (the London sales team, for example), so you add the new system to that role.

When it comes to your next certification cycle, you need the role owner to confirm that a given role still contains the right systems, and you need line managers to confirm their employees. Much easier than trawling around with Excel.


In between certification cycles, things are much easier too, especially when you tie your role management tool directly to your provisioning solution (this is pretty easy, as all support standards-based communication). If an employee moves within the organisation, you don’t need to worry about what systems they need access to, or cleaning up the access they had – you’ve just got to add the new role to their profile, and take the old one away.

Likewise for a new joiner or a leaver – their access is well defined, so you know exactly what to give, and what to take away.

So next time someone mails you a spreadsheet asking you to describe what a system does, and who should have access to it, tell them there’s an easier way.

Sun IdM & Virtual Desktop demo

WordPress taunts me every time I log in with the draft of a post I’ve been meaning to complete for quite some time that explains the general concepts around Identity Management, provisioning, role mining and so on. It’s intended to be a precursor to further more in-depth posts on various aspects of the topic. I never seem to manage enough time to finish it, so until then, a video!

At work we’re almost done with our first deployment of Sun Identity Manager. Personally, I’ve found it a good product to work with. I like Sun’s approach to deployment – the base system deploys as a Java WAR file that installs into Tomcat, Glassfish, etc, and it’s pretty easy to connect it to your first set of resources for provisioning. The workflow and forms design are a bit more of a challenge, using an XML-based functional language, XPRESS, and that takes a bit of getting used to, but is amazingly customisable.

Some while ago I was invited to a Sun technical day, at which I saw a demo of some SunRay thin-client appliances that link to the Sun Secure Global Desktop (SGD) product. If you’re familiar with Windows Remote Desktop, it works like this from a user’s point of view, except a bit more powerful. Stick your smartcard in the SunRay and connect to your desktop (Windows, Linux, whatever) running on a VM in a data centre. Go home from work, visit a web-based version and fire up the same desktop.

A couple of guys at Sun have put together a demo of how SGD, OpenSSO and Identity Manager can work together, dynamically creating whole new instances of desktops at a user’s request and giving the appropriate access, then killing it all off again when HR deactivate your account.

I think it’s a pretty cool explanation of how these sort of systems can hang together – for many organisations this could represent a huge saving in user administration, desktop provisioning, and even hardware.

Read about it here, or skip straight to the demo video (12 mins or so, with a great soundtrack!)

Homeland 'Security'

We got a notice at work this morning about the US Visa Waiver programme, informing potential travellers to the US that the system is changing. As of 12th January 2009, it’s mandatory to register in a US government online system at least 72 hours before you travel, unless you’re a US citizen or have a Visa.

Into this system, you must provide:

  • Applicant information (Birth date, full name, email, gender and phone number)
  • Passport information (issued date, expiration date, number and country of issue)
  • Travel information (flight and city)
  • Address whilst in the US
  • Health information (diseases, mental illness)

So, in itself, it’s amazing that you’re expected to give up all this personal data to the US government before you even leave your own country. Beyond that, there’s the risk that this system gets hacked, and someone steals all this data about you.

But I’m absolutely staggered by the popup disclaimer you have to accept on entering the site (I’ve added the bold emphasis):

You are about to access a Department of Homeland Security computer system. This computer system and data therein are property of the U.S. Government and provided for official U.S. Government information and use.  There is no expectation of privacy when you use this computer system.  The use of a password or any other security measure does not establish an expectation of privacy. By using this system, you consent to the terms set forth in this notice. You may not process classified national security information on this computer system.  Access to this system is restricted to authorized users only.  Unauthorized access, use, or modification of this system or of data contained herein, or in transit to/from this system, may constitute a violation of section 1030 of title 18 of the U.S. Code and other criminal laws.  Anyone who accesses a Federal computer system without authorization or exceeds access authority, or obtains, alters, damages, destroys, or discloses information, or prevents authorized use of information on the computer system, may be subject to penalties, fines or imprisonment. This computer system and any related equipment is subject to monitoring for administrative oversight, law enforcement, criminal investigative purposes, inquiries into alleged wrongdoing or misuse, and to ensure proper performance of applicable security features and procedures.  DHS may conduct monitoring activities without further notice.

So I have to give up significant amounts of personal data, and have no ‘expectation of privacy’. Makes me think twice about whether going to the US is even worth it.