SSO

SSO permits a user to login with a single action of user authentication and authorization(see also definition SSO Open Group).
So, with 1 action 2 different processes are executed: authentication and authorization. This makes it a very important access control mechanism in the identity management system of a company. A software tester who tests SSO should therefore split his testcase SSO in two testcases: SSO authentication and SSO authorization.
Otherwise he can't establish the origin of the defect when the SSO does not function properly.
To split the testcase SSO we have to look at the process of SSO and the parties contributing to this process.
First the process of SSO. Kjell Backlund from Emillion was very helpfull by sharing his knowledge on SSO and identity management with me.
He sees 2 possible SSO-configurations available for SAAS: web SSO and federated SSO.
With the help of SAML,an XML-based standard built in the SOA message , Web SSO is able to give an authentication message from one site (where the user is logged in) to the second site so the user can also log in on the second site. SAML can also function beyond the intranet where the user works on, because it is a webstandard.
Next to the user, XML and internet, 2 other parties are needed: the service provider and the identity provider.
Google Apps is using SAML this way in about 8-10 steps between the 3 parties. These steps can be evaluated by testing the different occuring SAML parsings and responses between the URLs of the parties. This is an elaborate process, and a lot of teststeps have to be taken.

One thing you have to take in mind:
SAML is just the messenger of the authentication information (it is XML), it does not perform authentication, nor authorization.It transports information from authentication authorities (eg. Active Directory) allowing identifying by for instance passwords or even biometrics.
This only shows the website the user is authenticated to log in.
A seperate rules engine, provided by the client, is necessary to evaluate attributes in the SAML-message if the user is authorized to enter the website.
This shows the different steps taken by SAML to tackle authorization and authentication.
Emillion has an alternative by ways of federated SSO, named Distal, where identity provider software can be eliminated from the process by server side scripting (ASP, Lotusscript, JSP) in the already available intranet of the SAAS customer.
From a testpoint of view this simplifies the testprocess because one of the parties is eliminated from the process.

But what about authorization and authentication when using Distal?
Distal can be integrated in web applications, application platforms and identity and access management solutions.The authentication messages can be built in the server side scripting of the clients intranet.
Authorization is more difficult, because it is a built-in feature of the clients intranet and with URLS this is difficult to tackle.
So, when considering Distal, a tester has a simpler testprocess considering authentication, because the identity provider is eliminated, although for testing authorization the tester needs the built-in authorization module from the clients intranet.

Concluding, SSO is a practical access control-method for SAAS-applications and different configurations are applicable.
For me, as a tester, Emillions Distal is a favorite because of its simpler test process for authentication. Considering authorization, this is still an issue for the SAAS client because the service provider has difficulties tackling the authorization rules by URLs.

Feel free to share your thoughts with me on this subject. I am very interested in the way Microsoft deals with SSO.
In my next blog-entry I will discuss the testing of another access management method for SAAS: OpenID