All-In-One Identity Management and Cloud Security

Single sign-on (SSO) makes life easier for end users; passwords and user accounts are eliminated and users just log on seamlessly to applications.  The problem is that not all applications are federated so you need one SSO tool that can provide SSO for federated and non-federated applications.  You also need SSO to manage both cloud and on-premise applications.  In other words, you need SSO to be made easier for your end users.

EmpowerID provides this comprehensive view of single sign-on, giving end users an easy, intuitive way to get to all of their applications, whether they are federated or not, on premise or cloud.  Take a look at this demonstration of EmpowerID's intuitive and simple SSO platform for your end users:

If you need SSO for your users, EmpowerID offers the fullest range of single sign-on, provisioning and authorization capabilities around.

If you want cloud SSO, you need cloud provisioning.  This isn't a brilliant revelation...your users can't log in to an account they don't have.

Let's take my favorite and most frequent use case: the wild world of Salesforce.com!  You want your users to be able to authenticate into salesforce without having to re-enter credentials or, worse yet, enter a completely different set of credentials.  So you federate with Salesforce.

Your user authenticates into the network using either her Active Directory or EmpowerID credentials.  She clicks on a link to salesforce and it quickly and invisibly redirects to the EmpowerID Secure Token Service which sends a SAML token to Salesforce which then accepts it and our intrepid user finds herself in Salesforce authenticated and ready to do work.  Without entering any additional passwords or user names.  Like magic, sweet federated magic.

The trick to this is your user needs a salesforce account.  And EmpowerID (or any other identity provider) needs to know what that user's account is.  Without automated cloud provisioning, do you manually provision each account?  Do you have each user claim their account to register it?  Do you put users in AD groups to establish access and hope against all hope that that group stays accurate?

Or do you integrate cloud provisioning with cloud SSO?  This way, users are provisioned and de-provisioned...automatically associating EmpowerID (or some other identity store) accounts with the Salesforce account?  Giving them the SSO experience when they should have it and removing that capability when they should not.  And, reducing the steps needed for users to get this capability.

So, what about existing users?  Do you have each user go and claim their account?  Users hate to follow IT instructions, we all know that.  So let's inventory salesforce.  All you need is a key (such as email address, conveniently your salesforce user name) and you can associate each of your corporate accounts to their salesforce accounts.

And the result, cloud SSO.  And made all the easier because of the connection between cloud SSO and cloud provisioning.  I have written extensively about this, about the connection between all aspects of identity and access management.  You need your provisioning to interact with your access governance to interact with your authentication to interact with your password management. 

IAM is a complex beast to slay, especially with the newer cloud aspects of today's world.  Having a complete platform that can be implemented in phases but still work together solves this and makes this beast much more manageable.

Let's start with the cloud.  Let's get your cloud SSO and your cloud provisioning working together.  Take a look at the federated SSO whitepaper and then schedule a demonstration of how EmpowerID will get your users provisioned and SSO'd to the cloud.

Security is not easy.  IT's goal is to find a way to increase security without adding complexity to the point where it reduces productivity.  It is a fine line and one that needs constant balancing.

Authentication is a key point on this security balance beam.  Password complexity, multi factor authentication, adaptive authentication, federation and single sign on are all considerations in how to deliver security without hindering productivity. 

Starting on one end of the spectrum (no security but easy for users) is a simple eight character password synchronized to all of your applications....that is not good.  On the other end of the spectrum you can have each application having a separate complex 16 character password with biometrics and identity proofing and an OATH token....your users will kill you.

I believe that targeted two factor authentication with single sign on is the answer.  Adaptive authentication is what makes this work.  Because EmpowerID is built on a visual business process oriented workflow platform, you can insert additional authentication options into any workflow based on either the role of the user authenticating or based on the application that the user is tying to access.

Examples of these two options are:

• Adaptive authentication based on the user's role: All users should be able to authenticate into the network with a password but more highly privileged users (domain admins or VPs of finance) should have a higher level of security.  These users will be placed into a role or group that requires a second authentication factor such as an OATH token.  (note: I find it very interesting that those with the highest level of access tend to be those who can control their authentication level such as CxOs or domain admins)
• Adaptive authentication based on application:  This option will result in much less resistance and one could argue is actually more secure.  When a user tries to access a more highly sensitive application or resource, the EmpowerID workflow will recognize the resource as security level X and apply a more stringent authentication method such as knowledge based questions or an OATH token.

The key to all of this is that the IAM platform must have workflows that can increase authentication levels based on either the user's role or the resource's security level.  EmpowerID's visual workflow can even make a hybrid model of this where certain roles accessing certain resources can trigger the advanced authentication.

It is also crucial to use the correct second factor.  As you know, the first factor is what you know and the second factor is what you have and the third factor is what you are.  Remember that balancing act between security and productivity?  The productivity side also incorporates how hard it is to get the second factor into your users' hands.

How hard is it to get iris scans or fingerprints for every user?  How hard is it to deploy smart cards for remote users when you have a 5% turnover per year?  How difficult is it to manage physical assets to manage the "what your users have" factor?

This is what makes smart phones so darned valuable.  Everyone has one.  The flip side to the BYOD revolution is the first three letters: users bring their own!  You can take advantage of this by having users register their devices as part of the authentication (yes, EmpowerID can do that for you).  Then either text a code or demand an OATH token as the second factor.

There are plenty of open source apps available (for example, this one for the iPhone) for the OATH client so you don't even have to deploy hardware.  EmpowerID has its own OATH server, creating a simple seamless way to incorporate an open standard such as OATH and the widely available smart phone from your users to create a very flexible adaptive authentication method using two factor authentication.

And you get to balance productivity and security by selectively applying this second factor to highly secure and confidential resources and highly privileged users.  Additional security without sacrificing productivity.  Schedule a demonstration of EmpowerID and see how we can make that a reality for you.

Believe it or not, we federate every single day in the real world.  The whole concept of federation is that a "service provider" trusts the "identity provider".  In the case of federated single sign on in the enterprise, this means that Salesforce.com (the service provider) trusts Active Directory (the identity provider) and allows you access.

In the real world, the best example is your driver's license.  When you present your driver's license to the bank to prove that you are you, the bank (service provider) is trusting that the DMV (identity provider) has properly vetted you with birth certificates, social security cards, or other identity information.  Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you.  They trust the DMV (or whatever institution in your country provides driver's licenses) to have taken the appropriate steps to prove your identity.

Don't get me wrong, IT systems are the real world.  And you just need a mechanism to trust your identity provider.  And something akin to a driver's license.  Thankfully, we have several standards that act as a driver's license: SAML, OAuth, OpenID, WS-Trust and WS-Federation. 

When a user authenticates into the service provider (in this case Salesforce.com), Salesforce.com asks for ID.  Since the application is federated with empowerID, the user doesn't have to pull out all of her identity documentation, she just needs the driver's license, in this case a SAML token.  Reaching into her wallet (actually the secure token server in empowerID), she pulls out her SAML token (actually, empowerID sends it to the service provider) and presents it as evidence that she is who she says she is and should have access to the application.

Since Salesforce.com trusts the identity provider and hence the SAML token, the user is authenticated and allowed in to the application.  No username and password (analagous to the mess of identity documents like birth certificates, etc) or difficulties in signing in.

There are other Federated Single Sign On Scenarios (this is scenario number 1, corporate login to cloud application).  But in each one, consider the SAML token (or other protocol) to be the driver's license.  Your user presents this token as identity proof to the bank teller or airline ticket representative or retail clerk and that person (service provider) trusts that you are who you say you are and lets you in.

Once you have this capability, it is easy to trust partners, customers, contractors, and other entities inside or outside of your organization and offer them single signon.  Imagine you are a book publisher who wants to sell books and offer other service options to consumers, authors and editors in an external portal. 

You won't get very far if you are forcing them to re-enter passwords and user names for each application.  Once you authenticate them once against empowerID (your identity provider), they are federated into every single one of those applications.  And the best part is that unlike the real world, they only have to reach into the secure token service once for that SAML token, it moves along with them presenting itself every time they hit a federated application.

Take a look at our whitepaper and see if any of these scenarios apply to you and let's make federated single sign on a real world solution for you.  Click the button below to download your copy of the whitepaper.

Cloud provisioning and single sign on go hand in hand.  IT wants only the right users to have the right access to cloud applications.  Users want that access and to not be bothered having to re-authenticate (well, actually, they say things like "why should I have to enter another password" in a nasally voice usually).

The problem is that the Identity Management industry evolved from the on-premise world and is stuck in its own tracks.  Most vendors' provisioning solutions were either developed separately from their single sign-on solutions or just don't exist in one platform.  Most of the federated single sign-on vendors don't even have a provisioning solution.

So how do you get that perfect world of a user being provisioned into a cloud application based on their role (or something you know about them), getting the correct application role, and federating to keep the number of passwords down for your users?  And, to top that off, keep your security team happy by de-provisioning that user when their job changes?

You don't do it with cloud vendors or traditional IAM solutions.  EmpowerID's tagline is a "New breed of Identity Management" and this is why.  The platform was built from the ground up without the burdens of acquisitions or partnerships to create the full suite.  So, the whole product line shares the same RBAC model, the same API layer, the same metadirectory, the same visual workflow designer.  It is a true platform.

What that does for you is allow you to have the same workflow for role based provisioning for both the cloud and on premise applications.  Map your business roles to application roles and then apply those roles to role based authentication.  It means that if you provision a user in salesforce.com, you can federate using empowerID as the identity provider, giving the elusive single sign-on for that user.

And, you can get even more granular than that.  If the user is accessing highly secure resources, you can force two factor authentication only when the user tries to access that resource.  Picture this, your finance director logs in to Windows in the morning and checks her email and browses the internet to see what the markets are doing.  She clicks on the link to look at the accounts receivable report, empowerID sees that is considered highly secure, and sends a text code as a second factor authentication; she simply enters that code and is authenticated for all resources of that access level.  When she goes into salesforce.com to see the forecast, empowerID knows who she is and authenticates her automatically.

You have just increased security and ease for your user.

Now for the fun part.  Your finance director is looking at a commission report and realizes that she should be in sales.  She changes departments which is reflected in Peoplesoft.  EmpowerID inventories the HR system, changes her department and roles, which deprovisions her from access to the finance system and provisions her a new account in the cloud based marketing automation system.  She now has an account in the cloud application and single sign on to that app.

We have all been wanting the complete soup to nuts identity and access management system that handles all of this seamlessly.  The world got more complicated with cloud applications but having the new breed of identity management software allows you to provision to cloud applications, offer single sign on, and achieve your IAM goals.

Take 30 minutes for a personalized demonstration of empowerID and see how we can help you achieve all or some of these lofty goals.

The day after the second password was invented, users started to complain.  "How can I remember all of these?"  Insert some whiney noises here and you have the gist of most helpdesk calls.

IT made some progress with single sign on and password vaulting and all was kind of good.  Until the cloud happened.  What the heck are you supposed to do now?  Each user has dozens of cloud applications they need to get to and you don't really control them.

Thankfully, SAML and federation have happened.  You can federate these external cloud applications with your internal authentication and users can access all of their cloud applications right from the comfort and sanctity of their own desk with just one password.

Your users authenticate into the network once, you present them this fantastic SSO dashboard for all of their federated cloud applications (or on-premise, never forget on-premise) and they are off to the races, being productive and not calling IT.  Keep in mind that each tile above is a URL so they can bookmark them or you can present them on any intranet page you desire.

If your user has another federated application, they go to add application and you present them a new tile.

We call this Scenario 1 in our whitepaper on the Top 5 Federated Single Sign-on Scenarios, Corporate login to cloud application.  Some of the benefits to this approach with EmpowerID are:

• EmpowerID provides connectors and workflows to quickly and cost effectively provision application access in Cloud hosted or SaaS applications as part of the normal onboarding process
• EmpowerID maintains auditing and reporting of Cloud application login history as well as who has access to which Cloud applications
• The EmpowerID Login Workflow provides adaptive authentication security to consistently enforce strong authentication standards such as two-factor authentication and also device registration policies to control access from non-corporate devices
• Users only need to know one password

Chances are that your users are using many SAML enabled applications.  You can easily control their usage, provision and deprovision users, and provide seamless SSO.  This will save you money on your monthly SaaS bills, enhance productivity for the users, and provide security and auditing around the wild west of cloud applications.

Take a look at our whitepaper for more details or schedule a demo and get your users the one password they've been wanting.

At a back to school party this weekend, one of the parents asked what I did.  After I explained identity and access management, this parent sounded a familiar refrain, "why do I need so many passwords?"  After the perfunctory and admittedly glib, "because you don't use EmpowerID", I gave the real answer: because not everyone knows how simple it is.

Because it really is simple.  Federated single signon with SAML (Security Assertion Markup Language) is easy.  There are only three parties involved: the user, the service provider and the identity provider.  And IT controls both the service and identity providers (good luck with that user!).

I'm picking salesforce.com as an example because it is common.  Your user has an identity provider (in this case EmpowerID) which authenticates that user into the network.  They check their email and then get down to the business of making sales.  When they go to salesforce.com (the service provider), that user will be instantly redirected back to EmpowerID without them knowing.  EmpowerID knows they are authenticated and then sends a token to salesforce.com with that users credentials and the user is logged in to salesforce.com without them even knowing what happened.  They then make your company a lot of money.

The behind the scenes stuff isn't too much trickier.  You have to configure the identity provider (EmpowerID), the service provider (salesforce), and give the user the correct URL to log in.  We have a whole wiki article on configuring this federated single signon, but I'll summarize for the blog:

• create a Salesforce service provider in EmpowerID
• configure the SAML settings including:
  
  • Name and Display Name: These are the name and display names you supplied for the SSO Connection when you created it.
  • Issuer: This is the party issuing the SAML assertion attesting to the user's identity. The value here should be EmpowerID.
  • TargetIDP/SP URL:This is the URL for accessing your Salesforce.com account from EmpowerID. When first created, EmpowerID populates this field with the relative path to the SSO Service and Connection ID only. To complete the full path, concatenate this with the FQDN of the EmpowerID web server in your environment.
  • ACS URL: This is the URL to the Assertion Consumer Service for the application. The value here should be the base login for Salesforce.com.
  • Enable ACS SSO Connect Query String: This field should be deselected.
  • Login Workflow ACS URL: This is the URL to the EmpowerID Login workflow. This workflow verifies the identity and account ownership of any person logging in to EmpowerID.
  • Endpoint Binding: This specified the type of binding used for the SAML assertion. The value here should be "HTTPPost."
  • Authentication Request: Leave this field empty.
  • Format: This specifies the format of the assertion used to identity a user to the service provider, if any. The value here should be "Unspecified."
  • Account Store: This specifies the account store in which each EmpowerID is to place each registered account. When the SSO Connection is created, EmpowerID automatically creates the corresponding account store for the connection. When an EmpowerID Person claims and registers an account from the Corporate Salesforce SSO application, EmpowerID places their account in the Corporate Salesforce account store created for the application and links the account to that user's EmpowerID Person.
  • Login Tile Image URL: This points to the image that is used in EmpowerID as link for accessing the service provider.
  • Description: This is the description you supplied for the SSO Connection when you created it.
• Verify all of the settings

Configuring the service provider:

• From your web browser, log in to your Salesforce.com account as an adminstrator.
• In Salesforce, click on the Setup link at the top of the page, navigate to Security Controls > Single Sign-On Settings under Administration Setup and click Edit.
• Tick SAML Enabled to view the SAML sigle sign-on settings.
• Specify SAML 2.0 as the SAML version.
• Enter "EmpowerID" in the Issuer field.
• Browse for and upload the STS certificate used in your EmpowerID deployment.
• In the Identity Provider Login URL text field, enter the value of the Target IDP/SP URL for the Salesforce SP SSO Connection. This URL is used to access Salesforce.com accounts from EmpowerID.
• From the SAML User ID Type checkbox, select Assertion contains User's salesforce.com username.
• From the SAML User ID Location checkbox, select User ID is in the NameIdentifier element of the Subject statement.
• From the Entity Id checkbox, select https://saml.salesforce.com.
• Save your changes.

Configuring users:

Users logged into the EmpowerID Management Console can request that their Salesforce accounts be registered with EmpowerID by clicking on the tile. This sends the request to an approver. Once the request is approved, a tile for the Salesforce SSO Application is placed in the My SSO Applications pane, allowing users to seamlessly access their Salesforce.com accounts from EmpowerID.   That tile is in essence a URL, they can bookmark it, have it in the intranet or click from anywhere in the network for seamless federated single signon with Salesforce.

Once you have done this (and it is this easy with all SAML applications), you can solve that "I have too many passwords" problem and give me less to talk about at cocktail parties.

Check out our whitepaper on the top 5 federated single sign on scenarios or arrange for a demonstration of how EmpowerID can be your identity provider of choice!

Talking to a client the other day about enterprise to cloud access, it became apparent that before considering cloud SSO, cloud provisioning needed to be taken care of.  More than that, role based cloud provisioning.

And this is where it gets tricky in the IAM marketplace.  There are a few companies offering cloud single sign on and doing it well.  They just don't have the platform in place to integrate with the on premise world and do role based provisioning to the cloud as part of that solution. 

And, think about your business goal here for a second.  You want to make sure that the right users have the right access to the right applications.  So, first you need to do role based provisioning; anyone in sales and support needs access to salesforce.  Only those users should be provisioned; after moving to another department they should be deprovisioned.  Data security is one thing to consider but so is license consumption...you pay monthly for these licenses.

Once you've provisioned the correct users to the cloud application (in this case salesforce), you need some role mapping.  That sales rep should have different access than the sales manager than the support rep.  Map your corporate roles to the cloud app role and not only do you get user accounts for the right folks but they get the right access.  As they move jobs, the dynamic role in your enterprise directory maps to the cloud role and presto boomo, accurate access to cloud applications!

And, now for the thing that people worry about.  Cloud single sign on...federating with the cloud application.  This is arguably the least important step but the one that gets the most attention.  Who cares if you only need one password if you have the wrong users getting access?  Luckily, it's possible to do all three and leverage the same directory if you can do SAML federation from the directory that is handling the cloud provisioning and access.

There must be others doing all three aspects of this cloud provisioning, but if any of this rings true to you, schedule a demonstration of EmpowerID and see how to get the right users the right access to the right cloud resources, and SSO them while you're at it!

While talking to a customer today, he mentioned that Google Apps didn't have a self service password reset option.  I can't say I didn't believe him, but I was a bit incredulous.  Gmail has a password reset, why not Google Apps?

I quickly googled the situation and found this in the Gmail section:

If your password isn't working, you'll need to go through our password recovery process. Google Apps users, please contact your organization's IT admin for help with password recovery.

Wow.  A service designed to reduce your organizational overhead requires helpdesk intervention to reset a password.

Once confirmed as a problem, what about a solution?  There are two ways to go about this, Google Apps password reset or Google Apps single sign-on.  It depends on your infrastructure I'm sure and I'm probably looking at this from a very EmpowerID-centric view, but neither is a difficult proposition.

Once you have your central identity repository (metadirectory) connecting to Google Apps, it's easy enough to utilize your current self service password reset solution to change your password and synchronize that with Google.  This only works if your self service password reset solution can call the Google Apps APIs and shoot along the new password.  This isn't always the case.

But if you go the extra couple of inches and federate, you take this password completely out of the equation.  Google Apps federated single sign on means that your users don't need to remember another password, their main network logon is all they need to know.  If they forget that password, the self service password reset solution you have in place already works; they change the password, sign in and BOOM, they are federated with Google Apps.

You no longer have to worry about Google's inexplicably missing password reset feature because your users are authenticated automatically and you have password reset in place.  As great as Google Apps password reset would be, Google Apps SSO is even better.

Take a look at this whitepaper on the Top 5 Federated Single Sign On Scenarios to see how you are going to architect Google Apps SSO into your environment.

Google apps supports SAML 2.0.  That is basically all you need to know to achieve single sign on.  In our Whitepaper, Top 5 Federated Single Sign on Scenarios, federating with Google apps falls under three scenarios:

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

But all of these scenarios follow the same basic principle -- the user goes to the service provider (Google Apps) which sends a SAML request to the identity provider (in this case EmpowerID) which sends an encoded SAML response which the service provider accepts and then, boom, the user is logged in.

This is federation which means the user doesn't even necessarily need to know their service provider username and password.  Here's a nice diagram from Google's developer page on how this works:

Google apps is growing by leaps and bounds in the enterprise and there is no reason to not have federated single sign-on for your users.  Choosing your identity provider wisely gives your users an easy way to access their services without re-authenticating.

Of course, you are going to have other issues with Google Apps such as the fact that their Google Active Directory Sync (GADS) only synchronizes 5 attributes natively and doesn't address how to synch your AD groups over to Google Apps.  EmpowerID can help you solve that as well, but in the meantime, get your users logged in and federated!