Five Minutes or less: OpenID

Most of the technical people I work with know what SAML is and how it works and how the federation protocols for SAML work (SP initiated, IdP initiated, Browser Artifact, Browser POST). OpenID is much less well known.

So here's what you need to know about OpenID in five minutes or less.

In OpenID there are three parties:

• The user and their browser.
• The Relying Party (sometimes abbreviated to RP) is the web site that's asking the user to authenticate. In SAML this is the Service Provider.
• The OpenID Provider (sometimes abbreviated OP) is the web site that's going to vouch for the user. In SAML this is the Identity Provider

Many people use the SAML and OpenID terms interchangeably when talking about the OpenID parties but I'll try to remember to stick with the right ones for this post.

OpenID works a whole lot like SAML's SP Initiated Browser POST authentication except for these differences:

1. All user interactions are via HTTP GET
2. The RP and OP communicate directly with each other via HTTP

Here's a simplified view of the flow:

I've broken the flow into three stages:

1. Choose OP
2. Login @OP
3. AuthN

Note: these are my own divisions and names; the OpenID standard doesn't break the flow up and doesn't have names for what I call stages.

Stage 1: Choose OP
The first step in the OpenID flow is the user telling the Relying Party which OpenID Provider they would like to use, often though the NASCAR style row of buttons. Under the covers each of those buttons corresponds to a URL and when you click the button the HTML form is actually submitting the URL to the Relying Party's web site. In some cases the site will allow you to enter a URL of your choosing.

When you send the URL to the site the Relying Party checks to see if it "likes" the OpenID Provider (usually by checking against a list of providers). If the URL looks OK the RP makes an special HTTP request, called an XRDS request, to the OP. The OP returns back a bunch of data describing the OP including the features and functionality that the OP offers.

A couple of other things happen here, but in the interest of time I'm going to skip over them.

If everything looks OK the RP redirects the user to the OP with an Authentication Request (via an HTTP GET with the data in the query string).

Stage 2: Login @ OP
When the user sends their Authentication Request to the OP the OP makes the user login. If the user has already logged in to the OP then that step might be skipped.

After the user has authenticated to the OP the OP generates an authentication response for the RP and redirects the user back to the RP.

Stage 3: AuthN
Finally... the user presents that authentication response to the RP (via an HTTP GET). The RP checks it out and if it's "good" then the user is considered logged in.

Finally the RP returns the content, application or whatever it is that they were trying to do at the RP in the first place.

How many connections do I need from the WebGate to the OAM Server?

Someone just asked the question:

My question is that, if we have 2 oam servers and assign 1 as Max Number of Connections for each server, does this mean that the webgate can handle only 2 connections at a time? Do we need to increase this value to enable the webgate to serve more parallel requests?

There is a relationship between the WebGate to OAM Server connections and the user to web server connections but it's not 1-to-1.

When a request comes into the web server the WebGate needs to figure out a few things:

1. is the resource is protected by OAM?
2. has the user already authenticated?
3. if yes to both should the user be allowed to see the resource?

Generally speaking the WebGate needs to send each question to the OAM Server and wait for an answer. That answer comes back from the OAM Server in milliseconds - the vast majority of which is actually the round trip time through the network to the OAM Server... there's nothing we can do about that pesky speed of light (damn you Einstein!).

Incidentally the connections the WebGate uses are opened when the WebGate gets started and are managed as a pool - when there are spares that haven't been used for a while they get shut down. When more are needed they get opened. The docs talk about how all of this works in pretty good details.

Many people start out thinking "if I want to support 100 concurrent users I'm gonna to need at least 100 connections from the WebGate to the OAM server."
Those people are wrong.
Plus they really shouldn't say "gonna" as it's not an actual word.

Consider these use cases

• a web server where you have hundreds of unprotected resources. In that case the first time someone requests the resource the WebGate will discover that it's unprotected. After that the WebGate knows the answer to question 1 and it doesn't need to talk to the OAM server for that resource again.
• a web server on which users keep reloading the same resource over and over during a session, for example if they're making mostly JSON or REST calls via JavaScript in an AJAX app. In that case after the first request by that user the subsequent requests will come out of the WebGate's cache.
• a web server mostly serving up very large files for download. In that case the answer from the OAM Server comes back in milliseconds but the download takes 20 minutes.
• or even 99% of the web servers out there on the internet where the user loads a page and then reads through the content for a few minutes before clicking again to read the next page or story.

In short: there's no good hard and fast rule about the number of connections you need from the WebGate to the OAM Server. Only testing your web site under representative load will help you figure out what the right numbers are.

And in that way the WebGate to OAM connection pool is a whole lot like connection pools from the Web Server to the App Server or from the App Server to the Database. And by a "whole lot like" I mean exactly the same.

Using the OIF Business Process Plug-in

There are a few extension points in OIF that allow you to easily extend or tweak the product's behavior. The one you're most likely to use is the Business Process plug-in.

I recently completed a PoC where OIF was the Identity/OpenID Provider and the customer wanted to send a bunch of attributes along to the Service Provider/Relying Party. All that is out of the box behavior. What's not OOTB is that they wanted to prompt the user to fill in any values that weren't in the LDAP directory before the user was sent back to the SP/RP.

The Business Processing plug-in gives you the opportunity to do that.

Using the nsstools to manage SSL stores for curl

While working on today's research project I also needed to test with curl. Sadly in my environment curl was built with NSS support which caused me some grief. I had never used NSS-enabled apps before and didn't know how to deal with their certificate and private key database.

I do now.

SSL/TLS fun with client certificate authentication

Today's adventure was a question about limiting SSL connections.

The customer's problem statement was along the lines of

I want to make SSL connections, using client certificate auth (i.e. two-way ssl) and have the server accept only one certificate. Can I put the one cert I want in the "trusted CA list" to do that?

I thought the answer was "no, that's not how you do that" but I wasn't 100% sure so off I went on a research project...