Protocol of the Month

In my previous blogpost I said I am going to explore OAuth 2.0 more in detail.

Bluntly said, OAuth 2.0 is an open source framework for online datasharing without using a username/password, but by means of access tokens.

This simplifies data sharing for a user and is also more secure, because you do not have to enter your password in a third-party site.

UMA,my pet identity protocol to test of the last two years, is build uponOAuth2.0, making it a OAuth 2.0 profile.

To understand UMA, you have to understand OAuth2.0 first.

This can get quickly technical, demotivating nontechnical users tounderstand OAuth.

This is a pity.

That's why I will discuss OAuth 2.0 and its different authorization flows in a series of blogposts.

Told in a functional way, illustrated with daily used examples like social networks.

If you want to have more technical details I recommend the IETF OAuth2.0 draft.

First,let's have a look at OAuth 2.0 and its roles.

There are four roles:

resourceowner

An entity capable of granting access to a protected resource.

When the resource owner is a person, it is referred to as an enduser.

resourceserver

The server hosting the protected resources, capable of accepting

and responding to protected resource requests using access tokens.

client

An application making protected resource requests on behalf of the

resourceowner and with its authorization. 
The term client does not imply any particular implementation characteristics (e.g.whether the application executes on a server, a desktop, or other

devices).

authorizationserver

The server issuing access tokens to the client after successfully

authenticating the resource owner and obtaining authorization.

This can be visualized like in this diagram:

source:  http://tutorials.jenkov.com/oauth2/roles.html

Obtaining access tokens is an important part of the OAuth2.0 protocol.

This differs per interaction the OAuth2.0 roles can undertake.

An access token is an example of an authorisation grant, a credential which represents the resource owner's authorization (to access itsprotected resources) used by the client to obtain an access token.

For granting authorization in OAuth2.0 there are four grant types:authorization code, implicit, resource owner password credentials,and client credentials, as well as an extensibility mechanism for deining additional types.

The next blog series will discuss the OAuth grant types

Stay tuned for my online adventures to unravel OAuth2.0 and interact with me through my blog, Twitter and Facebook.

Testing IAM: it's not only the identity that counts

For a month now I'm busy with testing an Identity and Access Management (IAM) solution build for a Dutch Energy company.
As you already might know by reading my blog, testing IAM is not only testing if someone can log in and out of an application.
No, there's more.
IAM stands for Identity and Access Management.
Identity management, a part of computer security, is about the management of identities and their authentication, authorization,and permissions within or across system and enterprise boundaries.
Access Management also relates to authentication and authorization, but includes Access Control too, which is perhaps a better word for it.
Next to this, Access Control is about measures such as physical devices (biometrics, encryption) and monitoring by humans and automated systems. Trends like Bring Your Own Device (BYOD) and 'Het Nieuwe Werken' (work anywhere any place any time) makes Access Control (and Identity Management) challenging:
People want to work with their devices perfectly in a secure and interoperable way.

This not only affects IAM, but also the testing of IAM: more and more complex testcases which has to be generated and executed in a short time.
These are just some thoughts from me. As you might have seen on Twitter or FaceBook I have started a TestingSaaS-FaceBook page where I want to interact with my blog readers and develop a social network dedicated to sharing knowledge on testing SaaS applications with a special emphasis on identity and security.

Why FaceBook?
I saw with blogging it was most of the time a one-to-one interaction, this social network could be an interaction where all blogreaders are involved and knowledge can be shared. So, if you have thoughts about testing IAM, drop by at my TestingSaaS- FaceBookpage and let's get this network started.

Testing UMA means testing controlling an individual's online data by himself!

One of the reasons I joined the UMA-WG, was that I wanted to be involved in a project right from the specs and not when it is time for systemtesting. Next to that, the concept of UMA fascinates me and worth making me sweat!
The active discussions we have about the testability of the specs inspire me to improve my work as a systemtester.
The implementations of UMA can be in legious domains: enterprise, government, education, e-commerce etc. etc.
This makes it a project where IT-architects from different domains can work together making user stories and use cases and improve this user centric authorization protocol.
Yes, we also have OpenID and OAuth, but, IMFO, OpenID is for authenticating the user and OAuth for authorizing it.
UMA let an individual control the authorization of data sharing and service access made between online services on the individual's behalf, as a layer on OAuth. It doesn't involve the authentication, but is very much dependent on OAuth and its possible changes, which are very much monitored by the UMA-WG.

A few years ago I started this blog, because I wanted to share my thoughts on testing SaaS and identity. The latter, because, IMFO, testers were mixing up authentication and authorization, which is disturbing, because it are important elements of web2.0, online user-interactivity.
With OpenID I started, but UMA drives me more because it is fresh, very user-centric and can be interoperable with OpenID through OpenID/AB, melting two of my favorite testsubjects (authentication and authorization) in one.

I wait for the day I can test an online user-interface (say banking :-) ) where an individual, with the help of the UMA-protocol, can control the data he or she wants to share with third parties, on the individual's behalf.

Something worth sweating for!