Archive | Security

OpenAM – Can’t Log on to Admin Console

This one cost me some time!

Symptoms

After installing and configuring OpenAM you’re unable to log on to the admin console with the amAdmin account and password you set during the install.  It doesn’t give an error message, just drops you back to the login page.

 

 

Cause

When you go through the custom configuration wizard you get asked for the cookie domain. If your OpenAM server is openam.mydomain.co.nz then your cookie domain should be .mydomain.co.nz but by default the wizard just takes the trailing two domain components from the server name – i.e. .co.nz. Unless you specifically set the cookie domain correctly you’ll get the issue described above.  As you can imagine this issue wouldn’t occur if your OpenAM server was called openam.mydomain.com.

This means that if you have a domain name with more than 2 domain components then you’ll always need to run the custom config wizard.

 

 

 

2

ADFS 2.0 – Choose Your Attributes Wisely

If you’ve read my last few posts you’ll be aware that I’m in the middle of implementing ADFS 2.0 for Web SSO. SalesForce for starters, with more to follow.  I’m yet to put it into production but I was thinking today and just having a bit of a sanity check and something occurred to me.  We send LDAP attributes as claims, the attributes are accepted by our service provider as law. They trust our federation service – that’s what federation is all about. Trust.  There are number of mechanisms that make it very difficult for someone to spoof an assertion. On the whole, the SAML protocol can be considered very secure.  What it can’t do is guarantee the validity of the source LDAP attribute.

 

Consider the scenario above.  We’re going to send the User’s telephone number as a claim.  Maybe unlikely but it could happen, maybe you’ve got a SaS provider and you’ve already got 500 users in the system and telephone number is the only field you know is accurate between you and them. Unlikely? I know.   But that’s not the point.

The issue is this – in Active Directory the attribute telephoneNumber, along with a few other attributes is by default, self writeable.

Once Dave figure’s out that the telephone number is significant he’ll update his phone number in AD to Bob’s phone number, launch the SaS app and will be logged in as Bob.

 

While there are only a few self writeable attributes in AD and they’re not ones you’d likely use for federation, it’s important to keep the whole picture in mind and the problem could go beyond self writeable attributes.  A couple of other situations I can think of off the top of my head:

  • Active directory self service applications which allows users to update attributes which aren’t normally self writeable
  • Identity management systems which synchronise other systems to Active Directory.  Not a problem in itself but you might be moving the point authorization for a specific application without realising it.

So choose your attributes wisely and make sure you know how, why, when and by whom or what they are written to before you decide to send them as federation claims.

4

SAML WebSSO & Federation Made Easy

 

This week I found myself on a SalesForce/SAML/Federation journey which turned out to be very enlightening. Until a few days ago I really had no idea how SAML or Federation worked and it took me a few hours to get my head around it, so I’m going to try explain SAML in a way that’s easy to understand.

SAML 2.0 (Security Assertion Markup Language).

2 Companies:
Company A (Service Provider – SP) has a web application
Company B (Identity Provider –  IdP) has a database of people who need to access Company A’s application

We have a few options here:

  1. Company A could create a new database of people with usernames and passwords within the web application
  2. We could synchronise the database of people including their usernames and passwords from Company B to Company A
  3. We could make a link from the web application to Company B’s database of people and do lookups in real-time
  4. We could tell the web application at Company A to trust users who come from Company B

Options 1 through 3 are pretty crappy.  Option 4 is called federation and it’s cool.

Here’s what happens (part analogy, part reality):

Both companies have a pair of keys. A public key and a private key.  Once something is locked with the private key only the corresponding public key can open it.  Company A has a copy of Company B’s public key and vice versa.

A user in Company B tries to access the web application at Company A.  The web application looks for a cookie in the user’s browser to see if he is already authenticated, he is not so the web application (SP) redirects the browser to Company B’s IdP, telling him – “Go and get a ticket!”

The browser goes to Company B’s IdP who authenticates the user against Company B’s database of users. The IdP at Company B locks the user’s employee ID with his private key, gives it to the browser and tells him – “Here’s your ticket now go back to the SP you came from!”

The browser goes back to the web application (SP) at Company A and presents his ticket.  The SP uses Company B’s public key to unlock the ticket.  The web application says to himself –  “It works! This user MUST have come from Company B because otherwise this public key could NOT have unlocked this ticket. And look, the ticket contains an employee ID and I have a rule that says that this employee ID is allowed access!” And so the web application gives the browser a cookie which allows him access.

 

In SAML the ticket is called an Assertion.  In this case we sent the Employee ID but any other user-unique attribute could be used, it just needs to be agreed between the 2 parties.

In reality the web application might not support SAML directly but instead maybe protected by a federation product which takes care of the SAML SP stuff.  The IdP stuff will also likely be handled by a federation product which is backed by some kind of LDAP directory or maybe SQL.  The browser cookie stuff mentioned above is outside the scope of SAML but I included it for completeness – It’s typical of how these things work.

 

The neat thing about federation is that you don’t need any links between Company A and Company B. Once the trust is established everything else takes place “browser to SP” and “browser to IdP” through a series or re-directs and http POSTs.

 

Ok so that’s SAML.  Actually there are a lot more parts to it than that but that’s the way it’s most commonly used today i.e. for WebSSO.  Now that you have the concept, you can dig into the technical details.

I found Google’s explanation useful:
http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html

and Wikipedia :

http://en.wikipedia.org/wiki/SAML_2.0

 

The best way to learn this stuff is to give it a go.  Check out Shibboleth which is an open source SAML SP and IdP implementation.  I’ve got the Shibboleth SP side talking to ADFS 2.0  as the IdP but I haven’t played with the Shibboleth IdP yet.

 

Next time I’ll show you how to put SAML to use with Active Directory Federation Services 2.0 and cloud provider SalesForce.  In the mean time feel free to ask questions or make corrections.

10