Challenges of Software as a Service
The adoption rate of Software as a Service (SaaS) has been dramatic in recent years. Trials of applications like Salesforce. com, WebEx, or NetSuite have transitioned to enterprise-wide deployments, and many organizations have adopted “SaaS first” policies.
However SaaS adoption is not without its challenges. The tendency of SaaS applications to be siloed has made managing user access and authorization an increasing challenge. The task of on boarding users is a time-intensive, manual process that involves administrators across multiple departments, which can introduce risk. Users hate having multiple passwords. Help desks hate multiple passwords too, since users forget them. Managing and synchronizing multiple passwords is expensive and problematic. IT departments must find a way to harness the benefits of SaaS, while minimizing business risk.
The Single Sign On experience for a SaaS Application
Providing single sign-on (SSO) lets users log in just once, then access many applications without needing to enter more passwords. It can also make organizations more secure by reducing the number of passwords that must be maintained. And for vendors of Software as a Service (SaaS), SSO can make their applications more attractive by letting users access them with less effort.
Single Sign-On is a process that allows network users to access all authorized network resources without having to separately log in to each resource. Single Sign-On also enables the organization to integrate with an external identity management system or perform web-based single sign-on to a SaaS Application.
Benefits single sign-on (SSO)
Reduced Administrative Costs: With Single Sign-On, all user authentication information resides in a central directory, which reduces the need to maintain, monitor and potentially synchronized multiple stores, as well as reducing user support requests around passwords.
- Increased ease of use: Each user only has a single username and password which grants them access to corporate resources and SaaS Application. Single Sign-On also saves users time, since each individual sign-on process can take 5 to 20 seconds to complete.
- Increased Security: Any password policies that you have established for your corporate network will also be in effect for a SaaS Application. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
Allowing SSO across as many applications as possible makes users happier, increases security, and lowers support costs. All of these are worthy goals. Yet providing SSO often takes work. And with the emergence of cloud platforms, new SSO challenges have appeared.
The Importance of Active Directory /LADAP integration of SaaS apps
In most enterprises, Microsoft Active Directory (AD) is the authoritative user directory that governs access to basic IT services such as email and file sharing. Often, AD is also used to control access to a broader set of business applications and IT systems.
SaaS applications are each developed with their own native user directories that control direct access to their individual services. And, because they run outside of the firewall, SaaS applications have traditionally been beyond the reach of Active Directory.
As SaaS application usage grows, this user directory duplication causes complication and hassle—for both IT departments and users. Users have to remember user IDs and passwords not only for their Windows network, but for each SaaS application as well. IT has to create and manage user accounts in both Active Directory and numerous SaaS applications, and must manually map AD users to corresponding accounts in SaaS applications.
Managing multiple separate user directories that are not integrated with Active Directory can easily lead to a set of untenable security and access management challenges. Seamless integration with AD is a must for any solution used to manage access and authorization to SaaS applications.
Some of the largest and most established SaaS applications offer their own AD integration tool, or they expose an API that allows you to develop a custom integration with Active Directory yourself. Google Apps, Microsoft Online Services, and Salesforce.com are all prominent examples of this approach. Salesforce.com has published APIs that allow you to build proprietary solutions that both push users from AD, and enable users to authenticate against AD when accessing Salesforce.com.
True integration with Active Directory must address all of these challenges and provide:
- Two-way user and group synchronization: As users and groups are added to and removed from AD, these changes should be reflected in the SaaS applications. In specific cases, SaaS applications should be able to push user profiles and groups to AD.
- Access provisioning and de-provisioning: When a user is added to AD, the relevant SaaS applications should be automatically provisioned and, conversely, when a user is removed from AD, SaaS access should be automatically revoked.
How ADFS (Active Directory Federation Services) works
With the launch of Windows Server 2008 R2, Microsoft released Active Directory Federation Services (AD FS) 2.0, which provides an extensible platform for handling single sign-on with applications outside of the firewall. This means organizations can leverage AD FS to address the SSO requirement of an AD integration.
Essentially, with ADFS, each company manages its own identities. But within a federated environment, each company can accept and provide permissions and/or access to identities from within another company. It all comes down to trust. The ability to trust accounts from one company without requiring a local account on your servers. This trust is called federated identity management and is the core behind ADFS. The biggest concern, logically, is security. All communication from one company’s Active Directory to the other’s ADFS is encrypted, and client access to through their browser is also encrypted using SSL.
It’s important to mention that ADFS is only for Web-based applications (like SharePoint). It’s really a solution only for allowing external business partners or clients to access your Web application, while still allowing the partner or client to manage their identities.
There are a few scenarios where you might use ADFS. One is the single sign-on where a person does have to log in one time through forms-based authentication, which will provide the users with a cookie that they can then use to access the rest of the site without having to provide repeat credentials. Another option is the identity federation option where they use their token from Active Directory to access the Web application without having to re authenticate at all.
Here’s a common scenario: A company developed a web application that requires a log-in. However, rather than promoting the site to individuals who sign up and create their personal log-in, promote the site to entire companies. A company with thousands of employees signs up to use the site and suddenly faced with the need to re-create thousands of accounts on the server. Users, when accessing the site, must perform the most frustrating task: logging in with a different account. Well, that is only one of many scenarios where people in one company need to access items in another company or have a single sign-on for another site, be it a single SharePoint site or some multi-tenant SaaS application that requires a log-in. Here is where it may be worth looking into ADFS (Active Directory Federation Services).