Thursday Jun 14, 2007

OpenID @ Work - Infrastructure Description

In my previous post I described our OpenID@Work overall architecture and flow. In this post I describe the deployment we adopted for this. A picture being worth a thousand words, here's an illustration of our deployment:

All traffic arrives through a load balancer that also serves as firewall and SSL terminator. The servers behind the firewall are run on a VIP. Server 1 runs Web Server 7 (more info here) on which we run the 2 instances of OpenSSO, the OpenID extension and the OpenID pages server (see previous post for details). Server 2 is a mirror of Server 1, mostly for load balancing and failover if needed. The users accounts are stored mirrored LDAP servers (servers 3 & 4). We use Sun Directory Server and plan to move to OpenDS soon.

For those of you interested, our servers specs are:

x2200 M2 with the following specs:
- 2 dualcore AMD Opteron Model 2218
- 8GB RAM (4x2GB DIMM)
- 2x250GB SATA HDD

Wednesday Jun 13, 2007

OpenID @ Work - Architecture

We finally officially launched our OpenID@Work identity provider for Sun employees (last week)!

I now have some time to describe in more details what we our service is and its architecture. This blog entry will describe the architecture we have put in place and to some extent explain our choices.

First off, here's a high-level overview of the OpenID protocol flow.

The steps are as follows:

  1. The user visits a web site (relying party - RP) that requires authentication. The web site being OpenID enabled, the user enters her OpenID identifier.
  2. The RP retrieves the corresponding html page. That page contains information on where the OpenID@Work provider (OP) is.
  3. The RP redirects the user's browser to the OP
  4. OpenID@Work performs authentication of the user
  5. Upon successful authentication, the user's browser is redirected to the RP and logged in.

Now back to Sun's OpenID deployment. Below is the list of constraints we put on this deployment:

  • The OpenID@Work service is only for Sun employees.
  • This is an opt-in program so Sun employees that want a Sun OpenID need to register.
  • OpenID@Work is an OpenID provider, not a relying party.

Now onto the architecture of our deployment. The figure below describes the overall architecture of our deployment.


The steps are the following:

  1. Registration phase - the user needs to go through a specific phase to register and obtain his/her Sun OpenID ID. The main difference with a standard registration is that Sun needs to make sure the principal is indeed a Sun employee. I'll describe those steps later on. This step leverages the OpenSSO's Membership module and is run in a separate instance.
  2. The user visits the RP and provides his/her OpenID ID (the URL).
  3. The RP obtains the URL from a web server instance (HTTP based) that only serves OpenID IDs (and FAQs)
  4. The RP talks to the OpenID module (an extension to OpenSSO) to create association key etc.
  5. The RP redirects the principal's browser to the OpenID instance for authN. The OpenID module will communicate with the second OpenSSO module and, if there is no valid session, OpenSSO will prompt the principal for authentication.
  6. The principal can at anytime log into the second OpenSSO instance to manage his/her profile (e.g. change password etc.).

In my next postings I will describe in more details some of the aspects mentioned above.

Monday May 07, 2007

OpenID at Sun

This is what I've been working on for the last (many) weeks:

Sun is deploying an OpenID enabled Identity Provider (OP in OpenID jargon) for its employees. Any Sun employee will be able to create an OpenID identifier and use it with OpenID enabled relying parties (RP).

Our primary objective is to figure out adequate uses of OpenID in the enterprise context. As SAML and Liberty supporters we know OpenID (1.1) is addressing a different market when it comes to delegated authentication. Its lack of trust establishment between the IdP and the RP is, in my opinion, one of the challenge OpenID is facing in a B2B scenario. By placing the IdP within Sun's DNS and controlling the OpenID identifier format we inject some of that trust in the authentication process. Consider the scenario where a company that does business with Sun offers a discount to Sun employees. In order for me to have access to the employee discount pages at their web site, Company A, in addition to my identity needs to know that I am indeed a Sun employee. I think combining OpenID and a certain for of trust of the IdP is ideal for that kind of scenario.

Our OpenID deployment (1.1 & Simple Reg.) is based on the module that was recently written by Paul Bryan as part of our open source effort OpenSSO. In my next blogs, I'll be posting a lot of tips and howtos directly related to this deployment.


Friday Mar 02, 2007

Deep-dive on SAML 2.0 vs. WS-Federation

After my previous blog entries on WS-Federation I received some requests for a more in-depth analysis of WS-Federation and in particular how it compares to SAML 2.0. It took me a while to get to it but I finally manage to spend some time  to do just that.

Below is a table where I compare both specs on various features and technical details. Note that each blue highlight identifies what I think is a plus for the specification (when compared to the other).



SAML 2.0


- Browser Redirect (messages in URL)

- Browser POST (messages in HTML form)

- SOAP (over HTTP)

- Artifact

- Browser Redirect (messages in URL)

- Browser POST (messages in HTML form)

- Artifact (reference to assertion + SOAP call)

- SOAP (over HTTP)

- Reverse SOAP (over HTTP)

Security tokens supported

- Those supported by WS-Trust (SAML assertions, X509 certificates, kerberos...)

- SAML assertions

- Any other token types (embedded in a SAML assertions via the SubjectConfirmation element)


- WS-Trust [1], WS-Policy, WS-SecurityPolicy.

- WS-Eventing to subscribe to Single Sign Out messages.

- WS-Transfer & WS-ResourceTransfer.

- None!

Identity federation

- Performed by the Pseudonym service (optional...) which provides identity mapping and its management.

- A Pseudonym service may be independent of an IP/STS and could store tokens associated to a pseudonym. 

- Identity mapping is part of the IdP. Although less (?) flexible it avoids the need for yet another protocol between the pseudonym service and the assertion generator (IP/STS in WS-\*).

- Mapping can be created either by the requestor (principal...) or the owner of the resource (SP).

- Mapping is created by the IdP but can be changed by either the IdP or an SP.

- All operations on pseudonyms (get, set, create or delete) are done via WS-Transfer (and its extension WS-ResourceTransfer to filter the scope of these operations).

- Client-based pseudonyms: a requestor can specify (in an RST) ad-hoc data for a pseudonym it wants to be used by the STS (e.g. PPID, DisplayName, email...)

- SAML does not provide a similar concept to the ClientPseudonym in its AuthNRequest. Is this one of the active requestor “benefit”?
The Name ID management protocol (and SPProviderID) is not meant for transient ID mapping.


- Description of the federation metadata format.

- Description of a secure transfer of this metadata.

- Can hold info about several federations.

- Description of metadata for SSO and more.

- Organized by roles (IdP, SP, Attribute requester, PDP...)

Single Logout

- Can be initiated by either an SP or the (primary) STS which will send sign-out messages to all RP.

- Similar


- Based on the use of a reference token (i.e. an EPR to which a WS-Transfer GET can be made to retrieve the actual token).

- Artifact profile (complete SAML response)

- URI binding (to only obtain SAML assertion)

- SAML also defines mechanisms to request or query existing assertions (by subject or statement type).

Authorization service

- Again a specialized STS.

- Concept of authorization context (name-scope-value) to condition the issuance of a token.

- The context seems to be a kind of pendant to the SAML2 XACML profile...

Authentication freshness

- A requestor can specify its freshness requirements (allow caching of security tokens etc.)

- Similar with Conditions and ForceAuthN

Authentication level

- WS-Trust defines the parameter (AuthenticationType). WS-Fed specifies predefined values (e.g. Ssl, SslSndKey, smartcard).

- SAML 2.0 offers a much broader & extensible set of authentication contexts.


- A requestor can express its protection requirements for security tokens it requests (protectData w/h claims & confirmation from STS).

- Privacy statements can be retrieved via WS-Transfer.

- SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxyRestriction, oneTimeUse, condition) [2]

- Those constraints can originate from both the SP or the IdP.

[1] WS-Federation basically extends WS-Trust to allow the issuance of tokens that can carry attributes or pseudonyms.

[2] One would argue that this could be achieved with WS-Policy but SAML has the advantage of offering built-in ones.

So what to think of all that? Well as already mentioned in previous blog I find WS-Federation to be very similar to SAML. I also think SAML is a more self contained specification; because of its composability approach, WS-Federation allows you to tune your deployment in many ways but it is done at the expense of simplicity. One has to go tweak WS-Trust or WS-Policy etc.

Some examples of what I can easily do with SAML 2.0:

  • I want to silently check whether the user is authenticated (I don't want the IdP to perform authN): set <IsPassive> to TRUE

  • I need an assertion with constrained validity or use: apply SAML's <Conditions>

  • I only accept authentication assertion from a list of IdPs: use <Scoping>

  • etc.

I have no doubt you can achieve this with the "right" combination of WS-Fed / WS-Trust / WS-Policy (and probably other specs) but with SAML it's all there...


Friday Dec 22, 2006

SAML vs. WS-Federation

Following my recent post on the (very) quiet publication of W-Federation, I was pointed at this excellent document that compares SAML and WS-Federation and explains why SAML is a better choice. This document is even more remarkable when one notices that it has been written by people working for the Government of Denmark obviously an impartial 3rd party.

I highly recommend this reading if you're in the process of selecting technology for identity federation or if you're just interested in understanding both specifications and some of their key differences. For those who don't have time I'm reproducing the main table in the Danish document below (I did not ask for permission but hopefully it's ok...):

 requirements  SAML2.0  WS-Federation
 Functionality related to requirements
Equal Equal 
 Support of the standard in commercially available products
 Microsoft support
 Proven usability from use in solutions in production
 Assessments by analyst companies
 Based on an adopted standards (e.g. within OASIS)
 Interaction with the other adopted standards, XACML and SPML  Advantage  
 Future development of the standard  Consolidation is expected
 Consolidation is expected
 Third party Interop Testing/Interoperability Certification  Advantage  


The document goes into more detail for each of those requirements and how the came to the conclusion presented in the table. I think this is a fair assessment of the situation!


Wednesday Dec 20, 2006

WS-Federation version 1.1 is out, 3 years after...

So, it seems Microsoft, IBM & al. have decided to release a new version of WS-Federation, more than 3 years after their first version. I've done a quick read on it and listed some of the most noticeable changes below:

  • Structurally there is now only one document. The passive, active and various interoperability profiles have all been combined in this single document. I tend to think this is a good thing since all these profiles were certainly creating confusion. IMHO they were also showing a certain lack of testing before the first publication hence leading to the need for additional interoperability profiles (but I'm being controversial here...).
  • All the protocols have been combined in a single big section (13)
  • The focus seems to be more on the active requestor rather than the passive profile which is mainly addressed in section 13.6

There are some new features in this spec too:

  • Federation metadata: with the concept of context to describe the fact of belonging to one or more federation (what SAML or Liberty Alliance calls Circle of Trust (CoT))
  • Authorization service & Pseudonym service: these are basically specialized versions of an STS in order to be able to include either attributes or pseudonyms along with the token that's being issued.

At this point it really looks like WS-Federation 1.1 is mimicking most of SAML2.0 functionalities although I think there are a few differences that I'll explore in a forthcoming post.
Finally, can someone tell me why in a world they decided to expand SSO as single sign-out when everyone else in the industry understands it as single sign-on ?!  Talk about confusing people...


Tuesday Nov 07, 2006

Federation Manager Bootcamp - we have contact...

As discussed in a previous posting, Sun Learning has come up with a great Federation bootcamp. I’ve received many inquiries for additional information and I’m happy to report that there is now an official email address fm-bootcamp-AT-sun-DOT-com you can contact (remember, this for Sun’s employees & partners for now).

Below is the “official” description of what’s on the menu for 5 great days...


The Federation Boot Camp course provides students with an opportunity to

learn about identity federation. Students learn about federation

concepts and specifications, then use Sun Java(TM) System Federation

Manager (Federation Manager) and Sun Java(TM) System Access Manager

(Access Manager) as a platform for demonstrating the concepts.

Topics include federation concepts, federation specifications and standards,

implementing federation frameworks, web services, programming and

customization, privacy, security, and high availability.

This course does not cover Lightweight Directory Access Protocol (LDAP),

Sun Java System Directory Server (Directory Server) concepts, and Sun

Java System Web Server (Web Server) concepts.

Students spend the majority of class time gaining hands-on experience

performing a variety of tasks typical of a federation deployment. Students

are quizzed at the end of each lecture and tested at the end of the boot camp.


Students who can benefit from this course are consultants, architects,

systems engineers, technical support personnel, and systems administrators

specializing in designing and deploying federation services using

Federation Manager and Access Manager software.


To succeed fully in this course, students should be able to:

\* Demonstrate proficiency with the Solaris(TM) Operating System

  (Solaris OS)

\* Demonstrate proficiency with XML and interpret Document Type

  Definition (DTD) files

\* Demonstrate familiarity with Hypertext Markup Language (HTML)

\* Demonstrate familiarity with Java programming and JavaServer

  Pages(TM) [JSP(TM) pages]        

\* Demonstrate familiarity with secure sockets layer (SSL), LDAP, and

  load balancers


Upon completion of this course, students should be able to:

1. Describe identity federation and identify problems that

   identity federation solves

2. Describe the Security Assertion Markup Language (SAML) 1, SAML 2,

   and Liberty federation frameworks, and deploy and configure Federation

   Manager to support those frameworks

3. Configure Federation Manager to support Liberty web services

4. Customize federation deployments

5. Identify security and privacy issues in a federation deployment

6. Configure Federation Manager to use Directory Server repositories

7. Deploy Federation Manager in a highly available configuration



\* AM-3480: Sun Java(TM) System Access Manager: Configuration and


\* WZT-AM-3481: Sun Java(TM) System Federation Manager: Getting Started


Preparation Lab 1 - Federation Manager Installation

\* Install Federation Manager

Preparation Lab 2 - SAML 1.1 Single Sign-on

\* Configure and deploy SAML 1.1 single sign-on

Preparation Lab 3 - Liberty Circle of Trust

\* Configure and deploy a Liberty circle of trust

Preparation Lab 4 - SAML 2 Circle of Trust

\* Configure and deploy a SAML 2 circle of trust  

Module 1 - Identity Federation Concepts

\* Describe identity federation principles

\* Describe problems that identity federation attempts to solve

\* Use identity federation terminology

Module 2 - Standards and Specifications

\* Describe the principal identity federation standardization efforts

\* Describe the SAML and Liberty federation frameworks

\* Analyze federation use cases and apply federation techniques to

  real-life scenarios

Module 3 - Federation Product Introduction

\* Describe the federation features in Federation Manager and Access Manager

\* Describe when to deploy Access Manager and when to deploy Federation Manager

Module 4 - Implementing Federation Frameworks

\* Implement single sign-on (SSO) with Federation Manager and SAML 1.0  

  or SAML 1.1

\* Implement a Liberty Identity Federation Framework (ID-FF)

\* Implement a SAML 2 federation framework

Module 5 - Liberty Web Services Framework

\* Describe the Liberty Identity Web Services Framework (ID-WSF)


\* Understand the Federation Manager Liberty web services implementation

Module 6 - Programming and Customization

\* Describe the nuts and bolts details of federation

\* Configure Federation Manager with metadata, a circle of trust, and a SAML2

  authentication module

\* Integrate JSP pages and the SAML2 API into a web application for federation

\* Demonstrate a federated web application

Module 7 - Privacy

\* Describe privacy in the context of federated identity

\* Describe examples of existing privacy laws and organization

\* Describe how the Liberty Alliance guidelines protect a principal's privacy

\* Describe which product features implement or violate privacy protection

Module 8 - Security

\* Describe vulnerabilities and risks associated with federated identity, and

  describe mitigation strategies

\* Describe how the Sun Systemic Security program and how its security

  principles can drive a secure federated identity implementation

\* Deploy a secure federation using Federation Manager

Module 9 - LDAP Back end for Federation Manager

\* Configure Federation Manager to use an LDAP back end for configuration data

\* Configure Federation Manager to use an LDAP back end for user profiles

\* Configure Federation Manager to use an LDAP back end for user

  authentication information

Module 10 - High Availability

\* List basic high availability concepts

\* Deploy Federation Manager in a high availability configuration

\* Describe implementation challenges and limitations

Monday Nov 06, 2006

Open Federation Manager is Here !

As promised, our engineering team has just posted the source code of
Federation Manager in our OpenSSO project.

The source code, labeled openfm, can be found HERE . If you’re interested in identity management and want to understand how Federation Manager implements the Liberty Alliance federation model this is it!





« July 2016