Friday Sep 11, 2009

OpenSSO Tab Sweep - Sep 11 2009

Wow - it's been months since the last OpenSSO tab sweep. Anyway - here's a collection of the latest news from the world of OpenSSO:

Now I can close a few Firefox tabs and relax. Have a good weekend, everyone!

Tuesday Aug 04, 2009

links for 2009-08-04

Friday Jun 19, 2009

links for 2009-06-19

Tuesday Mar 03, 2009

Swekey Authentication Module for OpenSSO

I just finished another OpenSSO Extension - this time, an authentication module for the Swekey authentication key (README, source). The authentication module prompts the user for their username and uses the Swekey to generate a one-time password, which is validated against the Swekey authentication server.

It's interesting to contrast the Swekey with the Yubikey, which I covered here a few months ago. Where the Yubikey emulates a USB keyboard, requiring no special client software, the Swekey requires a driver. On the other hand, where the Swekey is invoked automatically by a browser plugin, requiring no user intervention apart from inserting the device into a USB port, the Yubikey requires the user to press its button and, potentially, ensure that the cursor is in the correct input field. One thing they do now have in common, though: they both work with OpenSSO

So, if you have a Swekey, grab the authentication module, deploy it (see the README) and let me know how you get on.

Wednesday Nov 19, 2008

Yubikey Authentication Module for OpenSSO

I just committed a new OpenSSO Extension - the Yubikey Authentication Module (README, source). The authentication module prompts the user for their username and the one time password (OTP) from the Yubikey, calls the Yubikey authentication server to verify the OTP and authenticates the user (or not!) according to the response.

Many thanks to Jeff Bounds for inspiring me with his VIP authentication module and to Stina Ehrensvärd of Yubico for supplying me with a Yubikey to get started.

If you have a Yubikey, grab the authentication module, deploy it (see the README) and let me know how you get on.

Saturday May 17, 2008

links for 2008-05-17

Friday Feb 29, 2008

More on CardSpace Password Management

I wrote an entry on Tuesday about CardSpace as a Password Manager. Kim responded with a request: "I’d like to hear Pat’s ideas about the user experience of bootstrapping the passwords into the Identity Provider.".

Well, I see this happening at the relying party (RP) - if you already had an account there you would go to some 'change password' page containing the information card 'script' to invoke the identity selector and proceed as I detailed in the earlier post. When the identity provider (IP/STS) receives this initial request, it will see that it has no password for that RP/user, create (and record) a new one and send it to the RP, which will write it into the user's entry exactly as if the user had just typed it in.

If you didn't have an account, the relying party would do the information card thing as part of the signup, as an alternative to just prompting you for a password. In both cases, the relying party could display the password on screen (probably requiring a mouse click to 'unmask' it) so the user could independently make a note if she really wanted to.

In all three cases, signup, login and change password, it's the same code from the RP point of view - just a way of getting a password from the user. And, in both cases, the password could be nice and strong, since the user doesn't really need to remember it. One other detail is that the RP would need to communicate its password policy (e.g. 5-12 characters, alphanumeric plus !, @, #, $, %) to the IP/STS; sp:RequestSecurityTokenTemplate looks like it could carry that in its optional wsp:Policy element.

Going further, Gerry posted this morning on how the identity provider could even provide a series of strong, one time use, passwords, providing additional security, albeit with some incremental complexity at the RP.

Ben raises the bootstrap question, and also says (paraphrasing slightly) "If we derive an RP password from a master password and the RP site’s name, we can eliminate the IdP and do the whole thing locally, using the master password.". Yes - I use Hashapass to exactly that, manually (of course, I saved the page to disk, examined the JavaScript and only ever run it from my disk copy), but there are some trade-offs here. One is that this is yet another piece of client software to get onto everybody's machine. Not impossible, but a hurdle. The other issue I see is the 'keys to the kingdom' attack. If an attacker obtains the master password, then all the RP logins are compromised instantly and the only mitigation (as far as I can see) is to go round each and every one individually, changing passwords and cleaning up any mess. With an identity provider, there is still a master password that can be compromised in the same way, but the mitigation is rather different. Change your password at the identity provider and (assuming the identity provider has this information) obtain the identity provider's record of which RP's you've authenticated to. If you were encrypting the passwords in transit between the IdP and RP, you wouldn't even need to change your password at any RPs, since our attacker may have logged in as you, but would not have any of the RP passwords.

Now, Eric Norman commented:

I don't get it.

In this scheme, all three of IdP, identity selector, and RP need to speak the information card protocols. If they do that, then why not just use the regular information card stuff?

Is there something missing in the information card protocols whereby these password tokens would add value? If so, what is it?

This looks to me like it's just adding more code and complexity without adding any value.

That's a good question - where is the benefit here, and to whom? Well, the benefit for the RP over the regular information card model is that the RP does not have to correlate Information Card Private Personal Identifiers (PPID's) with user accounts. At the cost of adding some minimal code to the login process (parsing username/password from a posted information card token, rather than from the usual form fields), the RP enables CardSpace login. The RP doesn't need to add a PPID column to its user table and doesn't need a strategy for linking incoming PPIDs with existing accounts. If the RP is running some off-the-shelf web application, with no access to its underlying user management model, this could be very useful, indeed.

For the user, this allows them to use strong passwords with a huge potential population of web sites, all based on a single authentication to their identity provider, this authentication via an identity selector such as Windows CardSpace, rather than a web page in a browser.

For the identity provider, this is a value-added service that it could either charge for, or (more likely) provide free-of-charge as a competitive differentiator.

Tuesday Feb 26, 2008

CardSpace as a Password Manager

You might have noticed the exchange between Ben and Kim over the past day or two... Ben made a point that CardSpace makes OpenID redundant - why not just send a password to the RP? Kim jumped all over him - somewhat misinterpreting what Ben later describes as one of my most diabolical hungover bits of prose ever. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; Kim says "Hmm... Food for thought" (okay, I'm paraphrasing); Ben admits he didn't explain himself too clearly to begin with; and, glory be, they're violently agreeing. Phew! I thought we were going to be seeing handbags at dawn...

Reading all this lit a spark in my mind of how this could work. The crux is to consider the username/password token, usually sent as one of a set of possible input tokens to an identity provider security token service (IP/STS), as an output token.

Here's how it would work... Borrowing a diagram from Microsoft's Guide to Interoperating with the Information Card Profile V1.0:

First of all, the IP/STS would specify ic:RequireAppliesTo in the managed card. This tells the identity selector to include a wsp:AppliesTo element in the wst:RequestSecurityToken (RST). The IP/STS is going to need this later...

Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the 'service requestor' (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username/password token by specifying a token type of in the policy.

Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP/STS, and the IP/STS supplying it, exactly as in the standard information card interaction. Here the IP/STS could require any form of input token, but username/password is most likely.

Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user's credentials in a WS-Trust RST and send them to the IP/STS.

Now, here's the interesting bit. The IP/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the wsp:AppliesTo element, and looks up the user's username/password pair for that RP (this is an implementation detail - there could be a mapping of RP identifiers to username/password pairs per user, all encrypted on disk, of course). The IP/STS packages them as a wsse:UsernameToken, which is then encrypted with the RP's public key and returned to the identity selector (step 10). The display token could just show \*\*\*\*\*\*\*\* for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.

Here's the other nice bit... All the RP has to do is to decrypt the incoming token and it has the user's username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP - no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.

Friday Feb 15, 2008

More on ActivIdentity 4TRESS and OpenSSO

Marc Puverel at ActivIdentity emailed me today to point out that ActivIdentity provides an online service for 4TRESS evaluation. As Marc says, it's all in the docs:

ActivIdentity provides an online service that you may use to evaluate the Sun OpenSSO integration with ActivIdentity 4TRESS Authentication Server. In such case make sure your platform has access to Internet, then you can use the following settings:

  • 4Tress URL Endpoint:
  • 4Tress Channel Code: CH_WEB
  • 4Tress Authentication Type Code: DYNMC_AUTH
  • 4Tress Authentication Mode Synchronous : SYNCH
  • 4Tress Security Domain: DOMAIN1

You will have to log out of AM as the administrator before you can test the login module.

To test the login Module, use the URL http://<FAM_HOST>:<FAM_PORT>/opensso/UI/Login?module=<MODULE_NAME>. You should see the following login page:4Tress LoginPage

If you use ActivIdentity 4TRESS Online service you can use the following credentials to test user authentication:

  • Username: CUSTOMER
  • Password: OpenSSO

You may want to evaluate Sun Access Manager authentication using Strong Authentication. Send an email to with the following information:

  • Company
  • First Name
  • Last Name
  • Email
  • Telephone
  • Country

ActivIdentity will provide you a personal user account and a list of One Time Passwords. You may use these pre-generated One Time Password to have an overview of the end user experience and the associated security.

So, you can give the new authentication module a try, even if you don't have 4TRESS installed.

Friday Feb 08, 2008

ActivIdentity 4TRESS Authentication Module for OpenSSO/Access Manager

Marina Sum (who must be just about the busiest tech author at Sun Developer Network these days!) has co-written an article with Michelle Cope, of Sun's ISV Engineering team, on integrating Sun Java System Access Manager with ActivIdentity 4TRESS Authentication Server.

The article shows how you can use Access Manager's session upgrade feature to protect particularly sensitive resources with the one-time password (OTP) authentication schemes in 4TRESS.

What is particularly interesting about this integration is that the complete source code is available as an OpenSSO Extension; if you already have ActivIdentity 4TRESS, you can read the article, download the source, build the authentication module and deploy it into Access Manager or OpenSSO. If you don't have 4TRESS, then call the good people at ActivIdentity, and tell them Pat sent you

Thursday Jan 10, 2008

links for 2008-01-11

Friday Nov 02, 2007

Access Manager FAQs and Identity Services at Sun Developer Network

It's been a busy couple of weeks, what with a trip to Tokyo, a typhoon on the day I flew out, an earthquake at home and the usual backlog of 1000 emails that follows any trip away from the office, so please excuse the recent dearth of blog entries!

On returning, I was pleased to see Sun Developer Network's identity pages have continued their expansion. The latest additions are:

Kudos to Marina and Aravindan for their tireless work on the Sun Developer Network identity pages - if you're working with Sun Java System Access Manager and related products, you should definitely subscribe to the feed .

Tuesday Sep 11, 2007

links for 2007-09-11

  • The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring the User to disclose their Service Provider credentials to the Consumer. An example use case

Thursday Apr 19, 2007

Securing Site Access With CardSpace and OpenSSO: An Overview

As you may recall from a previous blog entry, a little while ago, Martin Gee of ICSynergy (one of Sun's system integrator partners, focussing on identity management, federation and SOA) blogged about some work he'd done integrating OpenSSO with CardSpace. He's since written this up as an article for Sun Developer Network. It's a great overview of both CardSpace and the mechanics of extending OpenSSO to support new authentication mechanisms.

It's good to see folks innovating on OpenSSO, and it's great to see them documenting their work like this.

Wednesday Jan 31, 2007

CardSpace Authentication for OpenSSO

Quite excited to return from vacation today and find an email in my inbox from Martin Gee of ICSynergy (a Sun-partner system integrator specializing in identity management) pointing me to his blog entry on adding CardSpace authentication to OpenSSO. Martin does a great job of explaining his use case, linking a personal card to an existing account in OpenSSO, screenshots and all.

This is fantastic stuff - a great foundation for OpenSSO/CardSpace integration. I'm certainly looking forward to seeing the code made available. And, of course, it will work just as well with Access Manager, OpenSSO's almost-twin.




« July 2016