Single Sign-On & Single Sign-Out - user experience

Single sign-on is "a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session." - Definition from Whatis.com

In Single sign-out the user will be signed-out from all authenticated applications at a single sign-out


WSO2 Stratos demonstrates the SSO concept very well. This is how user SSO experience in WSO2 Stratos.

Firstly, you need to create a domain and register you tenant in Stratos. There'll be two follow up emails. One to confirm you email address and the other to give your account details.
Following up the mails you can login to you Startos Manager page, or you can simply sign-in using the given admin credentials.

The first page you see after sign-in from admin credentials is the Stratos Manager Home page. From here you can invoke various WSO2 products which appear as services.
With SSO enabled Stratos, you can access these services without having to re-login at each entrance point (at each point where it opens up a new service for you). It is because your username and password are already authenticated and you are permited to access these multiple applications.

Afterwards, Say you have opened sevaral services where you were automatically logged-in and while you were working on one service (e.g. Cloud Gadgets), another has gone on a session expriration. No issues :), When you accessing the page it will nicely validate you by itself and make the service availble in a refreshed session.

Now, if you signout from one of the software services by clicking the 'Sign-out' link, you will be automatically signed-out from all the accessed services. That's where you will notice that Single -sign-out is in place!!!

WSO2 Stratos, the first 100% open source cloud platform for enterprise applications

“At a time when IT developers can create a new application in one month, taking months to provision and deploy servers and systems no longer makes strategic or economic sense,” said Dr. Sanjiva Weerawarana, WSO2 founder and CEO.

Read on @ http://www.itpro.lk/node/6962

Testing Cloud Services

WSO2 Stratos is a comprehensive, powerful PaaS solution which, WSO2 released newly. It is based on revolutionary Carbon platform and is a self-serving, multi-tenant, elastic runtime for private and public cloud infrastructures.

In this new deployment, Stratos has enabled WSO2 products as services. With it whole WSO2 middle-ware platform is available in the cloud as services.

So how was these services tested. As Paul has mentioned in one of his blog posts (Cloud Native), there are a set of technical attributes that the team take account of, to work well in a cloud environment. Out of these, Mutlitanency and Self servicing abilities were tested with more emphasis in this alpha release.

Self Servicing

Self-service means creating and managing your own tenant in the Stratos application. With this one could register his own organization (tenant) and manage the services, users within it.

How you do this:

1. Access Stratos from https://cloud.wso2.com/ and you will have Stratos Manager who is the entry point to wso2 cloud services.
2. Register a tenant in Startos Manager by going through the registration process that is available there in main page. This is a very simple process where you are asked to give only the domain name, administrator's credentials and security captcha.

After a successful registration, you can sign-in to Stratos using the admin account which would be admin_name@domainname. For an example, if I have my domain as 'ranaweera.lk' and administrator as 'admin', I can sign-in as 'admin@ranaweera.lk'

So that's about registering. This initial user is called the tenant-admin. After registering the organization, the tenant-admin can;
 - create users within it,
 - create various roles and assign users to them,
 - enable\disable services.

Tenant-users can;
- login and access the enabled cloud services,
- deploy there own web services,
- deploy mashups,
- apply security, change policies, apply throttling, engage modules etc to these services.

Few illustrative cases on this are;




Managing users:
From Stratos Manager, if you access 'Users & Roles' option, it allows you to add new users and roles in addition to existing admin user and role. While adding roles you can select the set of permissions you need to assign to a certain role. A user can be assigned one or many roles and vice versa. This is similar to the user management functionality we already have in all WSO2 products.

These users who were added above, are called 'tenant users'. A tenant user can login to 'Stratos Manager' from https://cloud.wso2.com/.  The user credentials that the admin assigned at the time the user was created must be used here. After signing-in to Stratos Manager, he will see all the cloud services that the tenant-admin has enabled for the tenant.

He then can sign-in to the cloud services using the same credentials.


Theming:
The tenant admin also can update the theme of his tenant by going to 'Theme' menu. There are few default themes as well as a 'customize' option.

A theme  that is applied at the Cloud Manager level should be propagate to all the cloud services within that tenant.

Billing:

This feature lets the billing information for the tenant viewable by the admin role. This component is still in development stages, so there'll be more to be said under this in future..


All the above can be done without a third party involvement making it 'self serving'. It is for the tenant administrator to manage with his tenant users.

Multitanancy

Mutlitanancy within Stratos is the ability it provides multiple organizations to register ,  Stratos Manager and work simultaneously, within their own domain. Like in our real world scenarios here the details of one organization should be private and shared only within it.

Lets simulate a step by step procedure of creating this environment;

1. First create a tenant (tenant A) and add users to it.
2. Create another tenant (tenat B) and add user to it too.
The tenant admin and users of tenant A could only access\view\edit services within their tenant. The admin and tenant users in tenant B are totally blind about the existent of tenant A.

We can use this environment to run through scenarios such as below;

Multitanancy in mashups (js services):

If the Cloud Mashup Sever was enabled as a service and tenant admin sign-in to it. He can create a javascript service in it. Lets say our admin has created a service which scrapes updates from a site and sends emails to a set of recipients. This service should be available for other tenant users to view and use. They should be able to edit it depending on the permissions granted by the admin. This mashup should appear in the service list with the author's name.

Now if you sign-in to tenant-B. Neither the admin nor the users of tenant B can access or see the services created by tenant A users. Because the two domains are two seperate entities.
Of course there are a set of system samples which will be available for all users by default. These are deployed under 'system' user.


Multitanancy in task-scheduling:

If a user\admin from a tenant schedule a task, (This is available in Cloud Mashup Server, from Configure > Scheduled Tasks menu), it will be visible and operational only within the tenant which originated it.


Multitanancy in gadgets:

In the Cloud Gadget, it allows the users to add gadgets of their desire. It lets him design their own gadget environment by adding\editing\deleting new tabs, new gadgets in their environment. All these customization done by a user (may it be the tenant user or tenant admin) is strictly for that particular user's account.

And, also these settings are not shared among tenants!

Cloud Gadget also lets you a community feature which facilitates gadgets' rating and commenting. A comment or a rating submitted by one tenant user can be viewable by other tenant users. But they are not shared with another tenant.

There's also a feature which gives you an update on the number of users who are using a particular gadget at a given time. This count is based on the users who use the gadget within a given tenant. It is not shared among tenants.



Mutlitenancy in entitlement policies:
You can create entitlement policies by going to Cloud Identity. These policies that you create in your tenant will be used only within it. And yes, these xcml policies can be used among the could services you have within your tenant.

For an example you should be able to do what is said in here.


Multitenancy in keystores/relying parties:

Again, Cloud Identity lets you store your relying party certificates and keystores. Similar to other scenarios these also tenant specific and blind to other tenants.



Likewise there's more and more scenarios you get to exercise and of course 'apply' in real world using WSO2 Stratos, which has whole of WSO2 middleware platform available in a single environment as services. Instead of having several servers started separately, here you have all the servers available at once. You can intercommunicate with them much easily.