Simulating SSO concept using axiom as IDP (An app on heruko) and Salesforce

SSO(Single SIGN ON) is a very vital concept and as a fresher to IT industry many of us struggle to understand the definition and importance. The aim of the blog post is to help you to  understand what SSO is and how easy it is to configure in salesforce.

SSO (Single Sign On) allows the end users to provide their credentials once and obtain access to multiple resources. The key point of the concept is that the users are not prompted for their credentials anew on access to participating resources until the
    active  session is terminated. 

     The participating resources are typically related, but still remain independent. 

    Specifically, each system may have own authorization system, providing system-specific      roles to the end users.

 We will be using an IDP simulator axiom on heruko to simulate federated SSO concept  with salesforce as the service provider .

There are four  ways we can have single sign on with salesforce and get authenticated .

1. Delegated SSO
2. Federated SSO
3. OAUTH
4. JIT SSO (Just in Time SSO)

I am not going to explain each one of these as this is not the aim of this blog ,having said that i have few good reference link which you can refer to understand the difference between each of them 

1)http://www.youtube.com/watch?v=8qTr4ulS-WU

The above link is an awesome webinar which explains all the four ways and there advantages and disadvantages 

2)There are some  blog posts on developer.force.com and these blog posts are very interesting read

a)http://wiki.developerforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations

b)http://wiki.developerforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services

c)http://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth

d)http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com

One of them,(first link a) uses salesforce as IDP and also as a service provider ,so two orgs are connected and explains the concept of SSO.These are valuable resources to spend time reading and configuring .

Now let me take some time to describe Federated SSO at high level .The above diagram will help me explaining the concept of Federated SSO.

In federated SSO uses SAML and we have an IDP(Identity Provider) and a Service Provider(SP).

The user makes a request to Force.com for a specific resource: This request may happen in a variety of ways for a variety of reasons. For example, the user may be following a bookmark, clicking on a link from an email, of allowing their browser to auto-complete.

• Force.com detects the user needs to authenticate and redirects the user to their SAML Identity Provider: Since the user doesn't present a session cookie, they need to authenticate. An organization-specific hostname allows the user's Org to be discovered, and they are sent over the SAML protocol. Along with a SAML Request, a form parameter called RelayState is passed along to the IDP. This captures the location of the resource the user originally requested

• The user accesses their IDP and authenticates. This authentication is performed by the IdP giving the customer complete control over the authentication process. A variety of popular techniques may be used, such as LDAP, a web access management system, Integrated Windows Authentication, or a 2-factor system such as SecurID.

• Once authenticated, the IDP sends a SAML Response back to Force.com. This response happens via the user's browser, and includes the RelayState originally sent by the Service Provider. The echoing of RelayState is critical to the success of the protocol, as this is what allows the user to be returned to the originally requested resource.

• Force.com processes the SAML assertion and logs the user in. The digital signature applied to the SAML Response allows verification that the message is from the Identity Provider, at which point the user is authenticated. They are granted a session and redirected to their original request.

Now come the actual part of practically simulating 

Here i will be using axiom a heruko app built just  for learning, testing, and troubleshooting single sign-on solutions for Salesforce.com

1)Configuration in Salesforce Environment 

This is very simple and let me go through this step by step with screenshots

a)So first step is to register a domain in my domain and set the redirection policy (Navigate to Domain management>my Domain in your salesforce instance 

b)Next step is to enable SAML 2.0 and configure the parameters for SAML SINGLE SIGN ON Settings

Once you enable SAML 2.0 as in below screenshot,the next step will be to download the certificate from axiom tool and upload in the SAML single sign on settings .Here are the screen shots to help you 

So i hope screen shots are clear to understand .So its basicallyits feeding the entity Id and SSO start page got from the axiom screen back to the salesforce and then in the below video i am going to demonstrate how easy it is now to simulate the whole behavior.Its no point more speaking in words i felt instead decided to put a video

Using Change sets Effectively For Enterprise Application Deployment For Force.com Projects

Deployments in force.com can be a headache specially if you are new to platform ,in fact you may mess up if you use changesets and have no experience before doing this or if you have come up from java/.NET background where you have used ANT for deployments and now asked to use change sets of salesforce

The aim of this blog-post is share some of the tips and tricks for using the changeset effectively for deployment.

So i assume here that we generally go through salesforce document and we are ready after going through salesforce document to explore some tips and tricks that i generally use for deployments when using change set

http://help.salesforce.com/HTViewHelpDoc?id=changesets.htm&language=en_US
https://help.salesforce.com/apex/HTViewHelpDoc?id=changesets_best_practices.htm&language=en

The above links is must read before you start reading the tips i have for using changesets effectively

Problem 1:The field level security and permissions of objects and fields are not obeyed once i deploy fields and objects using changesets 

http://salesforce.stackexchange.com/questions/15238/change-sets-including-custom-objects-and-custom-fields

So the solution is quite simple we forget that profiles and permission sets should be migrated along with migration of fields,objects,apex classes,visualforce,record types etc to apply the permissions 

Problem 2:Reports and Dashboards don't migrate properly

Reports and Dashboards do get migrated well with changesets .All that we need to ensure is to include the folders also that are necessary along with these dashboards .

There are two specific problems that i encountered 

i)In deploying folders or dashboard we get error saying the user with given mail ID don't exist in destination org 

Solution is simple, either we will have to remove the running user from the dashboard of  current org from which we are deploying or other way around to temporarily form  the user mail id in the destination org or may be create folders not deploying manually

ii)I received internal sever error when migrating reports and dashboards .

Internal server errors are meant for salesforce support but here is something that comes by luck sometimes

 If the destination organisation does not have folder sharing enabled then we cant deploy reports we receive internal salesforce errors.Manually enable in destination org to resolve this issue 

Problem 3:Deployed email templates in one go and in next go i deployed letter head and there was no association between email template and letter head 

This particular thing i noticed and looks like a bug but nevertheless,we must be careful in deploying email templates and letterheads .Its better to include both together to avoid such complains .

Problem 4:Its difficult adding fields to changesets when i have large number of fields or components 

For this lets hack a salesforce a bit .

So from the above pictures we will need to follow these to make our life simpler .First we will sort the fields by Type and then click on the "more" link found at the bottom.

Now the fields looks little better organised for the selection.Lets make it more easier .

si=-2&lsr=0&entityType=CustomFieldDefinition&rowsperpage=260

So observing the url once we click more, at the end of the URL we find a parameter called rowsperpage.This parameter holds no of rows that is displayed when forming the changesets .Now if we increase the rows per page from 260 to some large number 50000 we find we avoided pagination and now sorting on type again ,we find the interface is really selective and we need not paginate lot to add components into changeset.

si=-2&lsr=0&entityType=CustomFieldDefinition&rowsperpage=50000

Increasing rowsperpage avoids pagination and we can scroll at bottom to greater extent and avoids us to one more iteration to add components into changesets 

Disadvantages of Changesets 

Some of the disadvantages of changesets are as follows which needs some attention in future from salesforce

1)For standard fields and objects we will need to manually check permissions and field level security(manual activity or use force.com IDE)

2)Removing components from changeset is painful..yes its painful due to bad user interface and with no sorter available and pagination rendering is ajax one making more slower

Few Interesting tips 

1)The components in changesets are the very latest version components at that particular instance in the organisation.What i meant by this is say you formed a changeset at an hour before and one of the trigger got deactivated later ,say 10 minutes before you deployed into next instance .The trigger will appear deactivated in destination org as the current instance and code or build is taken during deployment .So make sure to form these only at time of deployment 

2)Approval process are available ,groups and queues can be deployed .If any issue its better to form queues and groups manually as this is simpler than debugging issue 

3)Be extra careful in adding metadata to changeset that have recently modified by salesforce during salesforce API release .An example to quote ,in winter 14 release only my sandbox was updated to 29 and my production was still on 28.0 and salesforce made some changes to Topics object and some unknown error was received during deployment .In order to avoid this i preferred removing that permission sets .

4)If some components is not getting deployed and if its config build and small effort prefer manually creating and removing same from changesets .Good thing about changesets is changesets can be cloned .

Hope this was interesting post!!Happy deployments and coding !