All-In-One Identity Management and Cloud Security

SharePoint has always been a good tool, but like most it's useless if it's not adopted (hello, self service password reset!).  You have to lower the barriers to entry for SharePoint use while maintaining a strict security policy.  You certainly can't make it so easy to use that your maintenance staff has access to your 10K report document repository.

The trick is SharePoint single sign-on (SSO), no?  Users authenticate into AD, get put in some groups, you go through the people picker and give site access to groups and BOOM, you're done.  No.  You're not done.  That works for about one day until users change jobs, you create a site for partners to access, you have a site for ex-employees to transfer their 401K, and so on and so on.

You need to fully integrate SharePoint single sign-on into your role based access control for employees, partners, contractors, alumni, customers, etc.  Use varying levels of authentication for each, you are able to offer SSO but utilize roles for what sites each has access to.  If the roles are dynamic (and they should be), you never have to touch them again.

But what does this have to do with single sign-on, that sounds like authorization not authentication.  Here's the key...each of those types of users (employees, customers, partners, etc) are going to be able to authenticate a different way and have access to the correct sites.  We call it adaptive authentication.

For example, a customer can authenticate into SharePoint using their Facebook credentials.  By having a SharePoint claims provider (such as EmpowerID), that customer is authenticated and has access to all public information.  If the customer wants to view their account information, they will need a higher level of authentication and they will be prompted to verify who they are with their customer credentials or EmpowerID account or even a second factor authentication like an SMS message.

The same thing happens with your employees.  The user logs in with their EmpowerID credentials and has access based on their role.  But we also bump up the authentication level and require an RSA token or biometric authentication when they try to access the company financials.

All of your users can access what they are supposed to with one set of credentials and they don't even need to have an Active Directory account to make it work.  BUT you are also able to selectively heighten authentication policy based on the role and site being accessed.  It's not a matter of just being a member of a certain group, it goes much beyond that all the while reducing barriers to entry for your users and keeping your security policy appropriately strict.

Take a look at what EmpowerID just did for a large healthcare portal with over 150,000 users authenticating to the portal via SAML, WS-Trust, WS-Federation and OAuth-based technologies from over a thousand different healthcare groups.

While having a discussion with a partner this week, he pointed out that enterprise single sign-on and federation are being confused much less often these days.  That led me to asking a few people what the difference is and finding that there is still confusion about the two.

So what is federation?  And how is it different from Single Sign-on (SSO)?

SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once.  It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”.  The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t.

Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or johndoe@example.com".  No password is required for the user to login to each system.  Because of the trust between the two systems, the target application accepts this token and authenticates the user.

The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth.  The benefit to federation is security and authentication into both on premise and cloud applications.

Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc. 

I like analogies; in my mind, Identity federation is like an amusement park.  With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk).  With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).  Feel free to use this one.

Even understanding this distinction, there are a lot of different implementation scenarios depending on whether you are initially authenticating on network or in the cloud, whether you are signing in to cloud or on-premise apps, or whether you want to manage Identity as a Service (IDaaS).  Download our whitepaper on the Top 5 Federated Single Sign-on Scenarios to see which one best fits your requirements.

Not all applications are created equal. For some corporate apps, everyone should be able to access them.  Some should be restricted to certain users, groups and roles.  Some even more sensitive applications should be restricted to certain users, groups and roles and have a higher standard of authentication.  We call this adaptive authentication.

Let's use examples:

• Corporate holiday calendar:  everyone should be able to access this just using their corporate logon.
• Salesforce.com app:  only users in the sales group or role should be able to access this.
• Financials ERP app:  only users in the finance group or role should be able to access this but you want two factor authentication and/or identity proofing before letting them in.

Single sign-on can and should accomplish all of these tasks.  For number one, it's a simple federation with the app (scenario # 3 in the whitepaper "Top 5 Federated Single Sign-on Scenarios").  For number two, it's scenario 1, corporate login to cloud application, pretty simple to do with SAML or OAuth.

Number 3 is the fun one that requires adaptive authentication for single sign-on.

This diagram shows the workflow used to accomplish this.  You set a level of application security in the SSO systems inventory.  Any application that is over level 5, for example, needs to have two factor authentication integrated into the login.  The user is logging in to the ERP financials system, the workflow checks that they have access and then before allowing authentication, it executes a second factor authentication (something you have to have, not just something you know like a password).

This second factor can be an SMS message, an RSA security token, and even be identity proofing from within the directory (what was your previous job title, what was your hire date, etc.).  Single sign-on is there to make your users' lives easier, but it should also improve security.

Schedule a demonstration of how EmpowerID can accomplish adaptive authentication or read the whitepaper on the "Top 5 Federated Single Sign-on Scenarios" now.

The traditional model for self service password reset drives me crazy.  The user gets asked questions to prove they are who they say they are.  And the system just resets their password.  Easy, right?  Secure, wrong.

Here is the issue, I can guess most of the answers to your questions by looking at your facebook timeline and the pictures on your cubicle wall.  Your first car, your daughter's name, your eye color, and so on.  That just isn't as secure as it should be.

What you need is two factor authentication with your self service password reset.  The first factor is the questions, in other words "what you know."  The second factor is something you have, whether it's a pager or mobile phone or a keyfob device.  With proper two factor authentication, someone is not only going to have to steal your user's memories but their phone also!

This still doesn't get you everywhere you need.  It is also important to have complexity requirements, either to match or exceed your Active Directory domain policy.  My own personal preference, make the complexity pertain to password length rather than crazy characters.  It's harder to hack a 72 character sentence than P@ssw0rd.  And it's easier to remember the sentence.

Having a proper password synchronization and SSO tool also improves your password security.  If users have a dozen passwords to remember they are going to make them easy to hack.  They are going to forget them a lot and use easy to hack questions.  Make life easier on your users and your security will increase...counter intuitive but true.

Get a second factor in your self-service password reset, it's easy and secure for your users.  Click below for a demonstration of how simple this can be.

The cloud is like the wild west right now.  Cloud applications are roaming the plains like gunslingers in a Spaghetti Western.  That's a crazy analogy but the point is that all the hard work IT has done over the last decade to corral identities within your network has been rendered useless in the cloud.

Everything you know about your user is rendered useless when they go out and create an account in the cloud.  A perfectly useful account for them to do their job but you in IT have no control over how they use it.  Or know what they're doing.  You have no idea what the user's cloud identity is: how they access it, what their account is, or if they should have access to it.

You need to understand their cloud identity.  The best way to get a user to buy in to IT knowing about their cloud life is to offer them something.  Cloud single sign-on is the best incentive to get users buy-in.  Think about it, if you want to know that weird little obscure account they are using, tell them you'll help them sign on more easily with their network account.

So, how do you integrate cloud identity into your network identity?  Workflow, beautiful role based workflow.  Let's take the biggest and most common example: salesforce.com.  In this example, you have 4 basic types of users who use salesforce: sales and service, user and manager.  Two departments, two roles in each.

If you have an IdM platform provisioning users and giving them roles (if you don't, please call us!), just assign a workflow that provisions the cloud applications like salesforce.  You know the user's role, so you can assign different permissions in salesforce to a sales manager v. a service user.

Once you've created the cloud account (in this case salesforce), you know the password, you have it linked to the user's network account.  You give the user single sign on to the cloud application.  Most cloud applications use some sort of standard authentication: SAML, WS-Trust, WS-Federation, and OAuth.  Now, between the provisioning, the SSO, and the role based access, you know what the user is doing in your audit and you have controlled the wild west.

Of course, in this scenario you have also controlled what they do on network.  And you might have dozens of cloud applications that you now control.  Identity in the cloud is NOT different than identity on the network, you just need a way to manage both together.

You want your users to be able to log in to the network, their on premise applications, their cloud applications and all of your partner applications.  You want your partners to be able to log in to the applications they need.  And you want this to be easy; both for the users involved AND for the IT security team that needs to make it happen.

A flexible stardards based federation solution is the key to solving these critical business challenges by enabling users to login once and then access applications without being prompted to login again.

Single Sign-on (SSO) is the most important service offered by identity federation because it allows employees, customers and partners to access multiple Cloud or internal corporate applications using a single username and password.  If done right, federated SSO allows users who are authenticated against one directory to access additional applications and services without re-authenticating hwne a trust relationship has been established.

The key to "doing it right" is to keep from re-inventing the wheel, there are standards to follow and trailblazers who have done it in the past.  We inventoried and queried our customer base to boil down the top 5 scenarios for Federated Single Sign-on (SSO); take advantage of our hard work to make things easier for you!

Top 5 Federated Single Sign-on (SSO) Scenarios

• Scenario 1: Corporate login to Cloud Application
• Scenario 2: Cloud login to Internal Application
• Scenario 3: Corporate login to Internal Application
• Scenario 4: Corporate login to Partner Application
• Scenario 5: Identity as a Service (IdaaS) Hub

In each of these scenarios, what differs is how the user authenticates and what they can access.  Using a variety of standards (SAML, OpenID, WS-Trust, WS-Federation, OAuth) and Identity providers (Active Directory, LDAP, Facebook, OpenID, Salesforce.com along with many others), these scenarios will allow you to ensure that the correct user can access the correct applications easily without extensive help desk calls.

A blog is no place for the technical how-to's of each scenario so we have published a whitepaper with a description of each, benefits of each approach and how to accomplish this feat.  Download the whitepaper and start designing your Federated Single Sign-on.