Edward Killeen

Recent Posts

Role based security with RBAC

Posted by Edward Killeen on Tue, May 22, 2012

Role based security means an awful lot more than just role based access control (RBAC).  It means using RBAC to its fullest potential to secure all resources in and out of your network.

role based securityThis means having an identity management platform that is built on the idea of roles.  Provisioning to different systems based on roles.  Granting access to resources based on roles.  Workflow levels based on roles.  Single sign-on based on roles.  Roles have to be core to the identity and access management platform that you choose.

IdM platforms built from acquisitions and hodge-podged together have a hard time having a core platform belief system like this.  The components need to be able to talk to each other seamlessly in the same language (not just programming language either).  For example, if you are provisioning only certain roles into salesforce.com, then your single sign-on has to understand that role and work with it, only allowing those users to even go through the SSO process.  Otherwise, you get moving parts; Frankenproducts love moving parts, business productivity doesn't.

A great example of this is rights-based approval routing (lovingly known as RBAR).  RBAR unifies workflow and RBAC security to enforce real-time evaluation and routing of who can approve what based on the actual rights delegated to the current person at that time for the affected resource.  Approvals route to approvers with the necessary privileges to perform the intended operation. Those rights are determined by your role.

Using RBAC and Attribute Based Access Control together is even better.  Picture you are in the Sales in Toledo role so you are provisioned into Salesforce as a user.  But you are a manager as shown in your title attribute in Active Directory.  Using the RBAC/ABAC hybrid allows your IdM platform to approve requests around Salesforce access and/or have extended privleges within salesforce.

Take a look at our whitepaper on Best Practices in Enterprise Authorization - the RBAC/ABAC Hybrid Approach.  You will get a great idea of how this all should work with a proper platform built with a foundation of RBAC.

Click me

Tags: Role Based Access Control (RBAC)

Top 5 Federated Single Sign-on (SSO) Scenarios

Posted by Edward Killeen on Mon, May 21, 2012

Federated Single Sign onYou 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.

Click me

Tags: Single Sign-on (SSO)