OpenID, an utopia for SAAS?

My last blog entry was about testing SSO. Now I want to discuss another access method for web-based applications: OpenID.
If you would believe the open source community, OpenID simplifies your online experience by using one single username for different websites. This is also the most important difference with SSO.
With SSO you have access to different sites by 1 single action of giving your username and password. With OpenID you log in with your username (OpenID URL) and password at one site and still have to enter your username to access other sites. This mandatory logging in with your username is less user-friendly than the single action signing-in of SSO, but can also be safer, because a person has always to fill in his username to have access to the websites of the SAAS-application.
Then why is OpenID not a common thing in the SAAS-community?
First, there is the security threat of phishing. For a B2B environment this can be a disaster. But there is another more simple explanation why OpenID is not so common used with SAAS.
Because OpenID is a single set of credentials to all sites supporting it.
That means all OpenID-credited sites have 1-to-1 agreements with each other and that also the different OpenID-providers are active on the same sites with each OpenID-provider authenticating access to the sites by users with other OpenID-provider.
This race for federated login is going on right now.
Maybe nice for B2C, but when considering B2B there are other issues to look after. Using OpenID, you have access to different websites using 1 URL.
In a B2B environment (SAAS) an employee has access to different websites, but he is restricted in his access due to the role(s) he has in the company. An employee can have many roles, making it impossible to squeeze all these different roles and corresponding access rights into 1 URL. Or the directory of OpenID should be coupled to a built-in authorization module from the clients intranet as I previously discussed in my previous post on SSO.
But why then use OpenID and not the SSO-solution Distal?

You might already guessed I am not so fond of using OpenID as a means of access management for SAAS-applications. I think more work should be done here to avoid phishing and authorization-problems. For the last problem, Microsoft claims to have the solution by combining its Windows Cardspace with OpenID. But that leads again to a manufacturarID and not a OpenID. Though I like to see the development of OpenID and Windows CardSpace, which seems to me a challenge to test considering the scenarios Microsoft gives here.

In my opinion, considering authentication, OpenID is, in comparison to SSO, still far away from becoming a suitable access management method for SAAS.
OpenID still has a lot of issues to attend which are less in SSO.
When looking at authorization, both access management methods lack a proper and safe authorization-module, so external solutions have to be sought in for instance built-in intranet authorization modules (federated SSO) or Windows Cardspace (OpenID).
So it's unfortunately not only testing SSO or OpenID, SAAS is a 'network' and should be tested as such!

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

Access Control and SAAS: a comparison of OpenID and SSO

A SAAS-application can be seen as a B2B-ecosystem of different stakeholders.
For usability every stakeholder should have a method of access control allowing him to gain access to the different areas of the SAAS-ecosystem.
How is this possible and what are the risks?

Here authorization and authentication play a key role. As is seen on Wikipedia authorization (deciding whether to grant access) is a separate concept to authentication (verifying identity), and usually dependent on it.

Both concepts can be seperately tested in a SAAS-application.
In my next blog-entries I will illustrate this by comparing two ways of access control for a SAAS-application: OpenID and SSO
Both access-control mechanisms are different and have to be tested differently.
The key question here is: Can a user login in a webapplication, which acts as a access control-gateway, and have access to other registered member-webapplications without being prompted or causing errors?
And, not less important, when this user logs out of the system, does he or she still have any access to the other member-webapplications?

See you on my next blog-entry which will discuss the testing of SSO .

For now, good luck with making a quality SAAS-application!

And don't forget, feedback on my blog-posts are welcome.

SAAS or SAS? that's the question!

Abbreviations are a common thing in IT.
But these abbreviations can lead to possible ambiguities.

This is the case when SAS (Software As Service) and SAAS (Software As A Service) are used.These two software model delivery systems look alike regarding their name, but are still different in their software delivery.
SAS is a melting pot of SAAS and SOA, combining the software-functionality without owning it (SAAS) with the composability and division- approach from SOA, enabling a network of SAAS-vendors and -clients. This last characteristic is very important for a testprofessional like me.

SAAS can be seen as a one-to-one relationship between SAAS-vendor and SAAS-client (e.g. CRM Salesforce), whereas SAS is a network of vendors and clients using the functionality of SAS (e.g. Google Maps).
This makes testing of SAS more difficult than SAAS because there are more stakeholders and the system is more complex. However, very important for a tester, because SAS is where it is going to on the world wide web.

The testprofessional who is responsible for testing the whole SAS-chain has to find out who is involved in the SAS-process, what they want with the SAS-application , how the vendors build their part of the SAS-chain and how they tested it. Otherwise he can't perform his end- to end-test/ big bang test in his test-environment.
The chain to be tested contains different modules of SAS-vendors and SAS-clients, coupled by interfaces. This makes the work of the responsible tester complex because he has to know the functionality of each SAAS-module and the functionality of the interfaces between each SAAS-module. This also requires documentation (even in an agile environment)
A tester has to know the desired functionality ,otherwise he can't test.

Just a few thoughts on my view of the future of SAAS and SAS.
More will follow soon.
Feel free to share your thoughts about this with me.

Going on rails with SAAS

Last week I finished a two-month test-job for Eurail.com, a small Dutch company selling Rail Passes to non-European residents. This company contracted other companies to build and maintain their e-commerce and fulfillment solutions.
That's why it can stay so small, because it 'outsourced' its IT to other foreign companies and still can have control over it by use of Service Level Agreements (SLAs).
For me, as a tester of this system, it was vital I knew what Eurail.com wanted with this new system and also to have a clear communication about this with Eurails foreign SAAS-partners.
I discovered railway e-commerce is a dynamic environment and changes every day.
To cope with this I made an initial dataset which had to be updated continuously and make generic testscripts for all parts of the e-commerce process.
And, like other testprojects, testspecification took a lot of time, but in benefit of testexecution, which took a shorter time.

That's my message this time: it is possible to test SAAS, but you do need good communication with all stakeholders and a generic testset and -cases so you, as a tester, can deal with a short time-to market.

Model based testing: A test methodology for SAAS?

Wednesday I attended an event organised by Testnet (Network Dutch testspecialists) where a presentation was being held about Model Based testing (MBT).
When listening to this presentation I wondered if MBT could be a suitable test methodology for SAAS. It is one for embedded testing in the auto-industry and also SOA
The presentation showed there was still a lot of work needed to optimize the testmethod, but it showed great expectations for testing SAAS.
MBT makes use of modeling (with UML) to test the code and is independent of the software methodology like agile etc.
This modeling makes it abstract and also flexible in changing the requirements when this is necessary for the customer.
Another positive feature is that MBT does the test design automatically.
At least, so it is said by the company Smartesting.
That's great, they even do smartesting-training, and no, this is not the same
as Smartest

Ome thing to remember is that MBT is used specifically during System(integration)test and not acceptance test. Here another model-based testmethod can be used: Business Process validation (BPV).
It is also not yet suitable for a big bang- or end to end-test, which we certainly would like to see when using SAAS. But the testcases can be used during systemtest by all stakeholders, so there is no mismatch about the cústomer's requirements.
Another thing is that the testers have to learn the modeling techniques to use this method. This requires some adapting, but we testers are used to that.


Concluding, MBT shows great expectations for testing SAAS with its automatic and modeling features and its abstract character makes it a testmethod suitable for every SAAS-application.
One to remember when choosing a teststrategy for SAAS.

Why this log from Cordny

G'dday,

welcome to my blog.

my name is Cordny Nederkoorn, a Dutchman who does software testing
for a living.
I started this blog because I want to inform you about my interests in
the testing of software systems based upon new software delivery models like
software as (a) Service and architectures like Service Oriented Architectures (SOA)
These architectures are becoming very important for businesses who want to deliver their services to their customers through the world wide web.

Although there are more blogs about SAS, SAAS or SOA, this blog distinguishes itself by focusing on the testing of Software As (a) Service (SAAS).

I will update this blog regularly with news from the SAAS-community and my feedback on it.