Sunday, December 6, 2015

Configure Salesforce as a SAML SSO service provider in WSO2 Identity Server 5.1.0

Salesforce can be used as a service provider in the WSO2 Identity Server. That means saleforce can be configured so that users are redirected to WSO2 Identity Server for authentication when they login. So the authentication process is done by Identity Server. This post will show you the necessary settings to set salesforce as a service provider in Identity Server using SAML SSO.

Settings at salesforce side.
  1. Go to Salesforce developer console and create an account. You will get a email to your email address to verify.
  2. Go to salesforce login and login. Check whether you are at developer console. If not click the drop down (down arrow) next to your user name at top right corner and select "Developer Console"
  3. Developer Console
  4. On the left panel, under "Administrator", click Domain Managment >>  My Domain. Create a new domain giving a domain id. It will take sometime to get the approval for the domain. You will receive a email within maximum of 15 minuets. 
  5. On the left panel, under "Security Controls", (above "Administrator"), click Single Sign-On Settings.
  6. Single Sign-On Settings page
     Click on "Edit" on top. Enable (Check tick) for SAML Enabled and save. Then click on "New". Give following settings on the following page.

    Single Sign-On Settings to use
    The settings for the super tenant at identity server. If you use another tenant please see below for the settings.
    • Name : SSO
    • API Name : SSO
    • Issuer : localhost
    • Identity Provider Login URL :  https://localhost:9443/samlsso
    • Identity Provider Logout URL : https://localhost:9443/samlsso
    • SAML Identity Type : Assertion contains User's username
    • SAML Identity Location : Identity is in the NameIdentifier element of the Subject statement
    • Entity Id :
    • Identity Provider Certificate : To get this first open a terminal and cd to location at {WSO2 Identity Server Home}/repository/resources/security/. 
              There you will see the keystore for supertenant as wso2carbon. Use following command at terminal. 

              keytool -export -alias wso2carbon -file wso2.cert -keystore wso2carbon.jks -storepass wso2carbon

    A file named wso2.cert will be created at the same directory. Upload that file by clicking on "Choose File" in above window.
    The above settings should work good if you are going to work with the super tenant at the Identity Server side. If you use another tenant then you will have to do following changes. Others are just as same as above.

    Lets consider the tenant as "". 
    • Entity Id :
    • Identity Provider Certificate : To get this login to the identity server management console with tenant user created at tenant Go to the keystore. In the left pane Manage > Key Stores > List.
    Tenant Certificate
    Click on Public Key as shown above. Download and save the ".cert" file. Now upload that file by clicking on "Choose File" in above window at salesforce.
    After all these click save to save SAML SSO settings.

  7. After saving settings you will be redirected to following page. Click on "Download Metadata", to download there metadata. Keep this file as we need it later.
Saved Settings
Settings at the salesforce side are now done. Lets look at the settings to be done at Identity server.

Settings for the Identity Server

You can skip the following step only if you are not going to use "Enable Signature Validation in Authentication Requests and Logout Requests" or/and "Enable Assertion Encryption" options for the service provider.

If you have started the Identity Server, Shut it down. Open the metadata file downloaded in the final step above, in a text editor.

Metadata File
Go to the samltool X.509 formatter and copy the whole text within <ds:X509Certificate> tag. (Highlighted above.) Paste that text in the "X.509 cert" box and click "Format X.509 Certificate" button. Formatted text will appear in the next box named as "X.509 cert with header". Copy that whole text to a new text file and save it as "salesforce.cert". 

If you are going to use the supertenant,

then you can simply copy this "salesforce.cert" file in to {WSO2 Identity Server Home}/repository/resources/security/  folder. Then like before at the terminal go to the {WSO2 Identity Server Home}/repository/resources/security/ directory and run below command. 

keytool -import -file salesforce.cert -alias salesforce -keystore wso2carbon.jks -storepass wso2carbon

If you are using another tenant,

start the server and login with the respective tenant admin user. Go to the Manage > Key Stores > List as before. Click on "Import Cert". 

Import salesforce certificate
Click "Browse" and select "salesforce.cert". Click "Import". You will see the certificate listed under available certificates.

Available Certificates in keystore list
Following steps are mandatory to set the Identity Server.

  1. In management console go to Home > Service Provider > Add. Give a name and click "Register".
  2. Register Service Provider

  3. On the next window expand Inbound Authentication Configuration > SAML2 Web SSO Configuration > Configure
  4. Configure SAML2 Web SSO Confgiuration

  5. Next give the following values to respective field. To get to know about SAML 2 Web SSO settings options in deep refer this awesome blog.
Service Provider settings
            Issuer :
            Assertion Consumer URL : This is the "Salesforce Login URL" in the SAML Sign On Settings window shown in the 5th step in Salesforce Settings.
            Certificate Alias : If you have gone the additional step above, "salesforce.cert" should be listed in the dropdown. You will have to select it if you are going to use "Enable Signature Validation in Authentication Requests and Logout Requests" or/and "Enable Assertion Encryption".

After all you can click Register to register the service provider. So the settings at two sides are done now. 

Let's create users at both sides.

Create Users at Salesforce

Log in to salesforce developer console.

To create a user go to Manage Users >  Users > New User. In the next window you will be asked for general information. User name must be in the format of an email address. (It doesn't have to be a email address. Just the format matters.) That is a limitation in salesforce.

Create Users at Identity Server side

When login your username should be identical with the user name you created at salesforce.
If you are using the supertenant users, you should enable <EnableEmailUserName> attribute properly in the identity server. Please find how to enable this feature in IS 5.1.0 from here. 

If you are unhappy to do that, we will find another hazlefree, easy way to do this with features provided in IS 5.1.0. For this you don't need to do above configuration. 

Go to IS management console. Home > Identity > Service Providers > List.  Select Edit of the salesorce identity provider to edit. Expand the Claim Configuration tab. Under the Subject Claim URI select Now the email address of the user will be used as the subject. Don't forget to Update the service provider.

Claim Configuration
Since you have set the SAML Identity Location as Identity is in the NameIdentifier element of the Subject statement at SAML SSO Settings at salesforce, this will work perfect. So please assure that you have set it.

Now go to Home > Identity > Users and Roles > List and select users to get the users. Select the User Profile infront of the user you are going to use to login to salesforce. Give the username of the user you have created at salesforce side as the email address and save.

Ok we have done all the settings needed. Shall we test it.  Start the Identity Server if it is not already running. 
Open a new Private Browser Window. Go to the domain you have created by pasting it at the address bar. You will be redirected to the Identity Server SSO Login page.

SAML SSO Login Page at IS 
Give the user name and password you have used to login to Identity Server account where you have created the salesforce service provider. You will be successfully redirected to the salesforce dashboard.

Logged in to Sales Force Dashboard

Friday, December 4, 2015

Enable Tenant Dropdown in Single Sign On (SSO) loginpages - WSO2 Identity Server (5.1.0)

When you have multiple tenants in the same Identity Server instance, it is hard to remember which domain you should use with username, to login. When you use Single Sign On to login you will be redirected to the SSO login page. Since SP1 of WSO2 Identity Server 5.0.0 new feature was introduced to help users to select the tenant domain easily from a dropdown in the SSO login page. This feature is not default. In this post you will be able to enable this feature in IS - 5.1.0. Method is almost same in IS - 5.0.0 SP1. For demonstration we will use the IS dasboard at https://localhost:9443/dasboard. Go to this link, you will be redirected to SSO login page.

Here you can enter the username as username+@+tenantdoamin, and login.

We are going to load the tenants into a dropdown and give the ability of select the domain from the dropdown. After this you will not need to enter the tenantdomain. Just the username will be enough.

Procedure :
  1. Open the file at path {IS_Product_Home}/repository/conf/identity/ Set tenantListEnabled=true.

  2. Open the file at path {IS_Product_Home}/repository/conf/identity/application-authentication.xml.  Add following before </ApplicationAuthentication> element. 

  3. <TenantDomainDropDownEnabled>true</TenantDomainDropDownEnabled>

  4. Open the file at path {IS_Product_Home}/repository/conf/tomcat/catalina-server.xml. Set clientAuth = "want", in the Connector for port : 9443 (what ever the port used by identity server management console)
If you are using IS 5.0.0 you will have to add following to the file at {IS_Product_Home}/repository/conf/security/authenticators.xml.

<Authenticator name="MutualSSLAuthenticator" disabled="false">
      <Parameter name="UsernameHeader">UserName</Parameter>
      <Parameter name="WhiteListEnabled">false</Parameter>
      <Parameter name="WhiteList"/>

This should be set default in IS 5.1.0. However better to check this also. 

After setting all these start the IS server and go to the dashboard at https://localhost:9443/dasboard.
You will redirected to SSO loginpage with tenant dropdown. 

Select the tenant domain from the dropdown. Now you can login just by typing the username (don't have to append domain name) and password.

Wednesday, July 15, 2015

OAuth 2.0

Please visit the OAuth 2.0 page for the explanation. This page updates with the latest information. A separate page was created to provide the most updated information to you.

The new comers may be so reluctant to go through a lot of text to know what is OAuth 2.0. This post is for you, my dear folks. Enjoy it and give your kind feed backs to improve the presentation. Find the explanation, video and a simple demonstration of OAuth 2.0.

You don't need anything else to start working with OAuth 2.0. Just forget everything else and read. You will learn more when you started working. Enjoy it. Cheers!!!

Thursday, June 11, 2015

Performance of switch and if-else ladder

What is the fastest way to implement conditional clauses in JAVA?

Answer : SWITCH  :) But in an even contest.

Almost all the times it is much more efficient to use SWITCH instead of IF-ELSE.
But the contest is important. We are talking about an incident where you use only one variable to check for equivalence with one value.(As shown in the following example)

There is a difference in the view of the INTENT. That is switch can only be used for one variable and only for equivalence. But if-else is different. You can use more than one variable and compare in different ways with different conditions. So it is not fair to compare the performance of a complex if-else control flow and a switch. What we are talking in this short article is the FUNCTIONAL difference in the low level between these two control flow structures.

Yet in an even contest switch is considered to be more efficient. Sure, you may have heard this somewhere, but you may not know why? Well, that may be the only reason you are here.

Lets' dig deep a little.

Though we code in English, the machine understands bits. So the compiler compile and change our English code into machine code via assembly. It is how the 'if-else' ladder and 'switch' is organized at this point, that make switch more efficient. 

There are few defferent opcodes for if-else implementation. Every one compares two values and if succeeds do a jump (I.E branching) to the offset given as an operand in the comparison opcode.  The success of comparison is decided by the opcodes.

Lets take an even example for both scenarios.

if (counter == 5){// do stuff}
else if (counter ==10){//do stuff}
else if(counter ==15){//do stuff}
else{//default stuff}
case 5 :
{// do stuff}
case 10 :
{//do stuff}
case 15 :
{//do stuff}

You can see the difference of the coding structure. Though the simplest control (in the code level) flow structure is if-else, in the byte level the simplest is switch.

A switch generates a hash-table with key,value pair (case value and branch offset pairs)or a binary search tree. In the case of hash-table time to find out the branch offset is always O(1). In the case of binary search tree the time complexity will be log(n). The difference is between table-switch and lookup-switch respectively.

Here n is the number of cases in the ladder.