SAML SSO with GoogleApps using WSO2 Identity Server

We are going to be using WSO2 Identity Server as the SAML provider for Google Apps. This is a valid scenario where an Organization's identity provider is an independent third party. Here is the scenario we are going to support.

Setup SAML SSO in your domain by following google documentation. https://support.google.com/a/answer/60224?hl=en

 The Sign-in page URL is in the form of, https://host:port/samlsso. The change password URL is pointed to the portal where employees use to change the password.

At WSO2 Identity Server Side, go to Main->Service Providers->Add. Now add the following configuration.

• The ACS URL is https://www.google.com/a/test.com/acs
• Since we have ticked the "Use a domain specific Issuer" above, our issuer is "google.com/a/test.com"
• NameId format is "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
• Enable Assertion signing (The corresponding certificate has been uploaded in the previous step into GoogleApps)
• Enable Single Logout and Attribute Profile

Note - test.com needs to be replaced by your actual domain name.

SAML SSO with Concur and WSO2 Identity Server

As of today, Concur supports IdP initiated SSO only. It has integration with many existing Identity providers such as OneLogin, Okta and etc .. Concur can easily work with WSO2 Identity Server (or any other SAML Provider) as well. This blog post will tell you how to configure WSO2 Identity Server with Concur Expense Management system.

Before you begin you need to get in touch with a technical contact from Concur side that will help to setup your certificate at concur side.  This is a manual step that cannot be done via online means. You MUST need the help of the technical contact at Concur side. Once you got the technical contact, here are the steps to integrate WSO2IS with Concur.

1 - Download and install the Identity Server according to the docs here. You can setup Identity Server with your cooperate LDAP store according to docs here.

2 - Now setup the Service Provider as follows.

Now the SSO should work! But you can go further to have a better integration with Concur.

Steps to go an extra mile.

3 - How can you publish a URL to the outside world as follows. http://accounts.server.com?spEntityId=concursolutions.com. Here you can add this to the internal app store of your organization and the problem is solved.

4 - If you want to provide authentication by federation only, then you can ask the technical contact to scramble the passwords and put up a banner in the page. The banner will appear like this.

5 - You can also allow users to register with authorization, but upon clicking on registration link then, the Concur admin can authorize and setup manager and additionally scramble the passwords themselves.

6 - If you want the Email link to work then the technical contact will update the link in the email so that the approvals will go the IdP first. The link will be something as follows. Please note the "hpo" and "cte" values.

https://accounts.server.com/samlsso?spEntityID=travelocity.com&hpo=4&cte=WHe$s78jMIcZE$..........OVKaiBzTI25SrSFKhSwQ7OPlB

The requirement is to insert the above values as Authorization Decision in SAML statement.

Then at the Identity Server side, I gave written an extension for SAMLAssertionBuilder to add authorization decision. What is the result? The approver will be redirected to the correct case on Approval page.

SaaS Identity and Directory Services

For SaaS providers, what are the available mechanisms for integrating with a directory service?

1. The LDAP can be fronted by an IdP hosted in DMZ that provides authentication and authorisation mechanisms to Cloud services. The authentication/authorisation mechanisms can be via web federation protocols such as SAML/OIDC. This is show in the above figure.
   


2. The LDAP (rather a replica of it) can be exposed via "ldaps" (ssl protected ldap) to the external Cloud services
   


3. The LDAP itself can be synced to the Cloud services. Technologies like Azure AD Connect can be used to implement this methodology

From 1st to 3rd mechanism, the security/privacy responsibility that lies on the SaaS provider increases.

In order to the 3rd mechanism, the users must trust the SaaS provider to store data and passwords. I believe, any organization will think twice before syncing LDAP with external parties.

So one might ask, hold on, what about online enterprise identity providers? Online identity providers such as OneLogin has obtained certifications to prove that data is private and well protected.  Obtaining such certifications are very expensive, and they needs to be maintained (audits must be done periodically).

The first mechanism can be illustrated as follows.

Federation Patterns - Why/How federated authentication only?

Federated authentication (SSO) and Service Provider maintained sign in can co-exist in the system, but this has account management problems. Consider your HR system has the following.

For example, when an employee leaves the organization, it is required to delete him from both places manually. This is error prone.

In order to overcome this problem, it is better if the system can give an option to disable maintaining passwords at their end, when there is an external IdP.

When an organization decides that they want federated authentication only, the system must provide a way to disable local authentication mechanisms. This means,

• Show only the Identity Provider Sign In option in login screen
  
• Forgot password link is not there in system login screen
• Existing passwords get scrambled
• Users cannot reset passwords from the their profile

Now comes the interesting question, how is my mobile app going to work? It can be done in One of the two ways.

• Users can go to profile and generate a pin number for the mobile app
• Implement SSO for mobile app. Here SAML based SSO is challenging because it is based on browser redirects but Native SSO support is available based on OIDC (Open ID Connect ) and OAuth

A blog post in WSO2 Cloud Blog

This week, wso2 cloud blog has published one of my blogs

http://wso2.com/blogs/cloud/your-own-jax-rs-as-an-oauth-web-api-in-minutes/

OAuth as a Service

WSO2 API Cloud brings you OAuth as a Service. If you are a person who,

• Has a service/API behind a firewall that needs to be opened up to the public
• Has ability to introduce a firewall rule

Then this blog post will explain, what you need to do.

In addition to OAuth protection, here is what you get after using WSO2 API Cloud,

1. Advertising to public in your own portal
2. Public developers will be able to get OAuth consumer secret/key from portal and call your API
3. You will be able to monitor API statistics such as - no of calls per service, who is calling the service
4. Throttle the API as required
5. Finally charge the API when that feature is added

High level architecture

 

Now you can instantly enable OAuth to your API. Steps,

1) Firstly, protect your API. If it is a JaxRS service protect using HTTP BasicAuth. If it is a SOAP service protect using UsernameToken. In step 3 you will see why we need to protect it.

2) Then get an account in http://cloud.wso2.com protect it using OAuth. Here is the tutorial on how to do it.

Now you have the API in a public portal.

3) Now contact send an email to cloud@wso2.com to get an IP, in-order to add a firewall rule enable this IP to talk to your service. We need to protect the service using username/password to avoid unauthorised access, because there could be an attack where unauthorised party trying to call the same services, if it is not protected.

Now you have implemented the architecture mentioned above.

Nginx for URL hash based routing

I wanted Nginx to do sticky-URL routing. One good way of doing sticky-URL routing is to take hash of the URL and route it between the available nodes.

There are several ways to do sticky-URL routing. Here is the LB configuration that I have tested with. It uses Lua. Lua is a very capable language.

1:  upstream wso2servers {  
2:    hash $urlpart consistent;  
3:    server 192.168.1.2:9763;  
4:    server 192.168.1.2:9764;  
5:  }  
6:    
7:    server {  
8:      listen 8080;  
9:      server_name router.wso2;  
10:      location / {  
11:         set_by_lua $urlpart "return string.match(ngx.arg[1],\"/t/.-/\")" $request_uri;  
12:         proxy_set_header X-Forwarded-Host $host;  
13:         proxy_set_header X-Forwarded-Server $host;  
14:         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
15:         proxy_set_header Host $http_host;  
16:         proxy_read_timeout 5m;  
17:         proxy_send_timeout 5m;  
18:         proxy_pass http://wso2servers;  
19:      }  
20:    }  

Now the more interesting question why someone needs to do sticky-urls? There can be many reasons, but mine was to achieve the most basic way of doing tenant partitioning. Tenant partitioning is explained here. As long as a string is representing the tenant is in the URL we can do tenant aware load balancing to achieve tenant partitioning.

Tenant Aware Load Balancing

Cloud service providers develop their software as SaaS applications to support multiple tenants within the same instance. In a public cloud scenario, it is required to support thousands of tenants utilizing a large number of clustered instances. In such a situation, it is required to properly manage tenant allocation per instance. It is not feasible to load all of tenants in all the clusters randomly. This would increase resource utilization. Tenants needed to be properly partitioned into different clusters to achieve optimal results. The following diagram shows an un-managed deployment vs. tenant-partitioned cluster.

Load balancing is a key function in a tenant-partitioned deployment, because we need to route the request to the correct cluster. Hence the term is coined as “tenant-aware” load balancing. Extensive research has been done on the tenant aware load balancing and the research paper [1] presents a reference architecture.

[1] http://www.iaas.uni-stuttgart.de/RUS-data/INPROC-2010-27%20_A_Framework_for_Optimized_Distribution_of_Tenants_in_Cloud_Applications.pdf

Multi tenant technologies as of July 2015

Multi-tenancy is for density. And density means cost. Higher the density lower would be the price that one has to pay for services and less isolaiton. The best statement about multi-tenancy is this line I from here[1]

"The more resources that are shared, the higher the density. Higher density lowers the provider's costs. At the same time, increased sharing reduces the level of isolation between tenants — the individual systems or services that are being delivered. Isolation is the degree to which one tenant can affect the activity and data of other tenants."

-->

	MT AppServer	OSGi MT	Java MT	Docker(Stratos)	VM
CPU
Heap size
Thread IO
File RW permissions
Disk IO
Bandwidth				Can count but cannot control

[1]  http://www.ibm.com/developerworks/library/j-multitenant-java/

How to setup App Factory 2.2.0 on a MacOS with puppet

 This is how to setup App Factory 2.2.0 on MacOS.

At Client Side (On your MacOS),

1 - First of all  you need to install puppet agent by following this guide https://docs.puppetlabs.com/guides/install_puppet/install_osx.html

2 - Then create a user as afpuppet and give him a password.

3 - Comment out the shell script that tries to generate a random number. This means you'll have to generate it by hand each time you run the sell script.

At the puppet master

Then install a puppet master following this guide - http://wso2.com/library/tutorials/2015/02/tutorial-step-by-step-guide-on-installing-and-configuring-wso2-app-factory-puppet-master-using-virtu/
Now do the following in puppet source in puppet master.

1 - Comment out the installed stuff in wso2base/manifests/packages.pp

2 - Fix the password problem. Meanwhile you need to comment out #managehome property also. Your wso2base/manifests/users.pp will look as follow.

You can generate the password from here - https://ask.puppetlabs.com/question/13940/creating-password-hashes-for-osx-109

4 - Fix the user group problem. Assign 'wheel' to the group

Now you are good to go.