All-In-One Identity Management and Cloud Security

The bane of every SharePoint project is permissions and rights.  Access is controlled via SharePoint groups, these quirky little groups that exist in the SharePoint vacuum and only in the SharePoint vacuum.  SharePoint 2010 introduced the ability to control access via Active Directory groups but gives no way to manage the membership of these groups.  So you end up with site admins managing permissions manually or just letting it die on the vine.

What if you could do true role based access control (RBAC) within SharePoint?  Have dynamic roles for your users that change as the user changes (new department, title, location, etc)?  And then manage site permissions with these roles?  Thanks to SharePoint 2010's claims provider functionality you can.

If you set EmpowerID as the claims provider for SharePoint, it exposes EmpowerID roles in the "People Picker", allowing the site administrator to pick a role (for example, HR managers in the investment banking division) to have access to that site.  These are the same roles that will be used for resource permissions or application access.  And it is possible to see who is a member (if you have permission to view membership of that role) from within SharePoint, making it possible to ensure that the right people have access to the right SharePoint resources.

The thing about roles is that they don't have some of the side effects that Active Directory groups do such as token bloat.  You can be a member of as many EmpowerID roles as you want without impacting your ability to log into the network.  On top of that, EmpowerID offers a polyarchical role structure so you can pick that HR manager role in investment banking from two trees, limiting the number of roles that you need to create.

Having a true SharePoint RBAC system also allows you to manage separation of duties since you can set an SOD rule that says a user cannot simultaneously be in two conflcting roles.  You don't have to worry about accidentally giving an investment banker access to the retail banking SharePoint site.

SharePoint RBAC is just a lot more flexible than managing permissions with groups (either AD or SP).  You get all the benefits of maintaining permissions dynamically without the overhead of managing a completely different set of access infrastructure.  This same claims provider functionality gives you SharePoint single sign on capabilities for your external partners for example without having to have AD accounts for them.

I have often said that to see EmpowerID is to love EmpowerID.  The reason is that when clients are looking for Identity & Access Management (IAM) solutions they fall in love with the idea of a complete IAM platform, one built from scratch on a single codebase that allows for seamless integration of user provisioning and management, access governance, federation, and audit intelligence.

Having these pieces together and interoperable gives the ability to integrate workflows that marry authentication and authorization in one place.  When provisioning a user account, you can create application accounts based on their role.  You can force a second level authentication if a certain role is accessing a certain application.  Separation of duties can be applied across multiple applications.

These actions aren't possible if your SSO solution is distinct from your provisioning solution which is different from your RBAC solution which is different from your audit solution.  Even when purchased from a single vendor, these are often "frankenproducts" built from various acquisitions and mergers.  If you don't have a single platform, you might as well have five or more.

EmpowerID puts all of these IAM capabilities in one platform.  That is what allows you to check the user's role when authenticating; to create a workflow that does identity proofing when accessing secure resources; to offer attestation for group and role membership or application access.  In short, to make identity management unobtrusive for a better user experience.

We had a call today with a gentleman who needed to provide access to twelve different web applications.  His choice with other vendors was to have federated SSO with the applications or have an RBAC solution.  With EmpowerID, he realized that he'd be able to have the two married AND add the user provisioning to all 12 applications based on the role of the user.  A complete platform for his IAM needs.

Schedule a demo, take a tour, and fall in love with a complete IAM solution.

Identity information is stored in directories; so it would stand to reason that directory synchronization is the key to identity and access management (IAM).  But that igores the Access in IAM.  Shuttling identity attributes between directories, databases and applications helps but isn't full Identity and Access Management.

Of course, directory synchronization is a great place to start.  You want your access to be granted dynamically based on who and what your user is.  An HR manager in Topeka needs a different set of access than a sales director on the Skynet account.  In fact, those two users need to be synchronized to a completely different set of directories; this is handled with role based provisioning, where only that particular role gets a user account and access in that directory/application.

EmpowerID puts a metadirectory in the middle of your identity ecosystem that will create "person accounts".  Each "person" will have joined user accounts in every system, database or directory.  If they are supposed to have an account in any application based on their role, they will be provisioned.  Once provisioned, attribute flow rules are defined to make either side authoritative or last change wins.  Constant inventorying of directories keeps them synchronized.

All of this constant change is sort of the engine for the rest of IAM.  Your directory changes are reflections of your user changes.  The person directory knows that you got promoted, knows that you changed phone numbers or have a new account.  This drives your dynamic role assignments that provision new user accounts, give an elevated level of access in salesforce.com or grant you admin rights in SharePoint.

The directory synchronization drives your identity...your rights, your permissions, your accounts.  You have to have this capability but you cannot let this capability be your only method of managing identities.

In the past, I have seen some of the largest organizations in the world get overwhelmed just keeping their directories accurate.  This back and forth and constant change (up to 20% internal turnover on top of 5% external turnover) takes too much time to have a chance of keeping on top of the finer more intricate IAM tasks.

But it doesn't have to be that hard.  Take a look at that graphic above, it's that simple.  Rules can be inserted to transform or edit values (one directory has first and last in one attribute, while AD has it separate for example).  Getting the correct attributes flowing throughout the organization is the fastest and simplest part of EmpowerID.

Once you are there, a corporate metadirectory becomes immensely valuable in identity management.

I often think of Gartner's quote on identity and access management: "the right people have access to the right systems at the right time" and think how do you know if they are the right people or the right systems or the right access?  We work with organizations with hundreds of thousands of users, does Bob in IT know all of them?

I'm being facetious of course, there's nobody in IT named Bob usually.  But that's where your identity and access management platform comes in.  It is busy giving people access to systems and you need to make sure that you are inserting the "right" into that sentence & process.

Having trusted authoritative sources really helps.  If you know that HR and other systems know all of the employees, contractors, partners and customers, you can usually cover the "right person" aspect of all of this.  But, that isn't always the case, so you have your first attestation option right there to solve the "right people" issue.

There will be a departmental owner or manager or HR person who can attest periodically that that user is still an active employee.  Build a workflow where somebody has to approve the continuing existence of that user account.  Not just a network account, but application accounts too.  Think of the savings if you periodically have users attest that they still need that cloud application account for which you are paying a monthly fee.

If the account hasn't been used or accessed for a certain period (say, 90 days), bump up the attestation.  It's easy to build this into a BPM-based identity workflow.  Make more secure application accounts have a higher degree of attestation involving identity proofing or two factor authentication.

So, with that user attestation process you solve the right systems and the right people but what about the right access?  Roles and group attestation helps solve this.  Have the role or group owner attest to the membership of the group and the group's rights and permissions on a quarterly or yearly basis.  Give them the audit reports to show what that role or group can do and who has been doing it.

This should all be built in to the identity workflows that come with your IAM platform, if not, take a look at EmpowerID.  Dont' just give access to people, give the right access to the right people.

End users know their stuff.  I know this isn't a common refrain in IT but if you're talking about the users themselves when saying "their stuff" then there is no dispute.  So for some identity information, you actually need the user.  And to offer identity management self service.

The most obvious and important identity store to consider is Active Directory.  There is a lot of identity information within there to delegate: mobile phone, home address, and other personal information.  This is the sort of identity information your company needs and can only be provided by the users themselves.  In fact, once they enter it via your self service interface, take advantage of this and flow the information back to the HR system.

The items above you can usually trust your end users to provide.  There are a few items where you want to have control, put some sort of approval workflow on it.  Take for example, business phone, maybe you aren't flowing this from your telecom database and want your end user to update it but want the telecom guys to approve it, shoot a workflow request to them before committing it to AD.  I can't stress this enough, self service liberates IT but you need to have controls in place.

AD groups are a common delegated item.  End users should be able to join and leave groups but not all of them.  Using rights based approval routing, you can set specific groups to require group owner or admin approval before joining.  In fact, some groups should be completely off limits to self service (think financial reporting).

But Active Directory isn't the only identity store in your organization.  The benefit to a full Identity and Access Management platform is that you aren't limited to just AD.  By having a metadirectory in the middle of everything, you can create self service forms to the metadirectory or directly to any connected application. 

A great example is when you need to apply for a specific role in salesforce or your jive community.  Having a self service option allows you to apply for the role, enforce an approval workflow and using the IAM workflows, set a time limit on the access (temporary privileged access).  As you can see, self service is not limited to Active Directory at all but it can be in the exact same self service interface.

Of course, don't forget that self service identity management has to be part of an identity ecosystem.  Any attributes, roles or information that your users provide through self service should flow back into your identity stores and any appropriate applications.

Let us take you on a tour of how you can make this identity ecosystem more diverse and robust through self service.  With control.

Users have a lot of accounts; it keeps both IT and users busy.  The trick is to give them the accounts that they need and only the accounts that they need.  Automated user provisioning is essential.

The "person" directory is the foundation of how automated provisioning should work.  A person account should be created for each user (full time employee, contractor, partner, customer, etc).  This person account should have enough information about it to start a chain of provisioning workflows that create a joined account for each application the user needs.  We call this role based provisioning.

Let's start with how to populate the "person" directory, or metadirectory.  The metadirectory will inventory an authoritative source (HRIS for employees, a spreadsheet for contractors {just kidding}, CRM for customers and partners) to check to see any new users and provision a person account with attributes flowing from that or any other system.

Dynamic roles are provisioned (assigned) based on those attributes.  Based on those roles, the user gets an AD account, a salesforce.com account, an SAP account, line of business app accounts, a Jive account, and whatever else their role and your imaginative workflow decides.  Role mapping determines the user's role in each of these systems.

This provisioning workflow is designed around your business rules and processes.  EmpowerID offers a visual workflow designer that has almost 400 out of the box templates and the power to customize each worfklow with 400 different actions or shapes.

The provisioning workflow is kicked off as soon as the metadirectory inventories the authoritative source and determines this is a new user.  The workflow will create the person and automate the user provisioning for the appropriate applications based on roles, creating mailboxes, updating appropriate group memberships and basically doing the work to make a user a productive employee.  This is automated user provisioning in a way that matches your business process.

Speaking of business processes, ever notice how there are some one off situations?  A user account needs to be provisioned through an alternate channel?  Opening up the applications (or ADUC) themselves is a security risk if you just have admins go in there with no means to audit access.  Using these same provisioning workflows, you can design a form, assign role based permissions and have an admin kick off the process through delegation.  It is auditable, access can be made temporary and when the metadirectory inventories the systems it will know from where this account originated.

In our years of experience with empowerID and automated user provisioning, we have seen that no two use cases are the same.  But the process almost always is.  With configuration (not customization), you can have your user provisioning process automated.

If you want to see how it's done, let's take an hour and demonstrate these use cases for you.  Schedule a demo now!

When you embark on an RBAC project, you have to consider that you already have roles in place.  Application roles, location roles, OUs, and security groups.  All of these have to be mapped to your management and organizational roles.

Let's start with mapping location roles to physical locations.  Your OUs are probably organized by location or geography.  Many of your RBAC permissions are based on location and you want to have a single parent role for each location with multiple OUs and directory locations mapping to the single location based role.

As you can see, you can map multiple external roles to a single empowerID role.  This allows you to manage more permissions and access with a single role in empowerID.

This concept becomes even more important with application roles.  A single sales manager role in empowerID can map to the salesforce.com role, the Exchange role, and the SharePoint role.  It takes you out of the business of managing roles and permissions in every single application on your network and cloud.

The benefit to you is that you can make the empowerID roles dynamic, have the user's roles change based on any attribute changes in Active Directory or any other connected system.  So that sales manager gets promoted to sales director and all of his/her roles change immediately.  Not only in empowerID but that streams all the way down to all of his/her application roles.

Take a look at our whitepaper on enterprise authorization and the RBAC / ABAC hybrid approach.  Or save yourself some wear on your reading glasses and arrange for a demonstration of role mapping for complete RBAC.

Highly privileged accounts can cause a lot of damage and do a lot of good.  There is a tricky balancing act between having IT users with too much privilege and not enough.  On one hand, do their job and on the other, perform mischief (such as accidentally delete an OU which is a real example).

I have seen extremes from one out of business retailer who let every user have access to Active Directory Users & Computers (ADUC) to minimize help desk calls to a very successful international bank who has pretty much shut down ADUC in favor of a granular rights based self service delegation through empowerID.

That second use case is the one I want to talk about.  Not just for ADUC but for all resources that you want to control access through RBAC (role based access control) or ABAC (attribute based access control).  One of my go-to sayings is: "what you can't automate, delegate."

Let's start with Active Directory.  IT needs to create accounts, groups, computers and other objects in AD.  The problem with AD and ADUC is that one size fits all.  The same user who can create a group can also create a user or delete an OU.  You have to shut that thing down. 

With a delegated Active Directory self service system, you can have specific roles have access to create, modify or delete only certain AD objects.  You can get granular enough that a user can even manage their direct reports or only certain attributes in their own profile.  And, you can put workflow approvals on any changes made depending on who made the request (rights based approval routing).

What about users wanting to join groups?  Same thing, create a form for users to request access to a group and send it through appropriate approvals.  Depending on the group or user requesting access, maybe even auto-approve it. 

Why even stop there?  Most users are joining groups to have access to a file or folder.  Use a self service page to request access to that resource and have empowerID map what group that user needs to be in.

But that's not the key here.  The key is that when privileged access to a role or group is requested, don't just give it for an eternity.  Temporary privileged access keeps that user from having permanent access to the role or resource.  Put a time limit on the user's privileged access.  Limit the exposure.

Other useful tools is to require multi-factor authentication (MFA) when the user attempts to use the access.  Before you allow it, require them to authenticate with an SMS text to a known device or identity proofing with something that only they will know.

The idea is that privileged access is needed for many users to do their job.  But give them this access only when they need it.  If they have it permanently, ensure it is really them by utilizing MFA upon usage.  Try to shut down any systems with all or nothing access and create an identity policy and system that gives users another more secure route to access.

And, lastly, track this stuff.  If you know when and for how long a user had privileged access and what user or policy granted this access, you have the audit trail to prove that you are keeping your corporate valuables safe and secure.

Take a look at our whitepaper on replacing ADUC and/or request a demonstration on how to reduce privileged access in your environment.

Getting a user provisioned and productive on your network is one thing, getting their cloud accounts sorted is a whole other ball of wax.  In the old days, you had Active Directory, Exchange, some line of business applications and ERP this and that.  Presto, boomo, you had a provisioned user.

Now if you want to automate the user account provisioning process, you need to account for any cloud applications the user has.  These cloud applications have different UIs, are owned by different lines of business and generally add a wrinkle to your identity and access management that you just don't need.

But it's the world we live in and we have to somehow manage cloud identities with our internal identities.  The three main things to worry about are: 1) provisioning / deprovisioning, 2) role based access control, and 3) federated single sign on.

Automating provisioning and deprovisioniong is the first and most important step.  You pay for these accounts monthly per user so if someone has left the company, you want that account gone immediately.  An IAM platform like empowerID will have connectors to all of your major cloud applications like Salesforce, Google apps or Hubspot.  For those without an out of the box connector, building one with the applications APIs is pretty easy. 

Unless your IAM solution can do role based provisioning, your user will always have this account though.  Remember that provisioning isn't a one time affair, it is a lifecycle for the user, make sure that your automated provisioning workflow (and deprovisioning) takes into account the user's role or attributes and deprovision the account if their role is no longer eligible for the application.

But provisioning these accounts is pointless if you still have to go into the application and manage the user manually.  Application level role based access control (RBAC) is built into most applications.  Most IAM platforms have enterprise level RBAC.  Role mapping is essential for cloud applications, map the enterprise roles to the application role during provisioning and as your user moves around the organization.  An example is Salesforce, if your user is promoted from sales executive to sales director, their enterprise role will change; a good IAM platform will then change their cloud application role along with it.

Last, but not least, is the federated single sign on.  Your users have increased their number of application passwords exponentially (that is a bit of an exaggeration), make sure that you are federating with your cloud applicaitons.  SAML and other standards have made this easy if your IAM platform supports it.  We have a whitepaper on the Top 5 Federated single sign on scenarios, take a look and see what matches your needs.

IT departments spent the better part of the last decade figuring out corporate identities.  Most IAM vendors built their "platforms" before the cloud became so prevalent.  EmpowerID was conceived and built from 2008 onwards with the cloud in mind the entire time.  It is a platform based on a single code base that allows you to manage the provisioning and deprovisioning of cloud accounts, their roles and access, and federation all within a single IAM platform.  You do the work once for all identities, whether it's internal or cloudy.

A demo of this complete ecosystem for your users' identities will show you how simple this can be to manage. 

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!