Courion Corporation

As Applications Externalize Authentication and Authorization...

Tweet

 

Overview:  Many systems and applications are adopting a model where they rely on an external system for their authentication, authorization and audit (AAA) requirements which raises a few security concerns.  Perhaps the most common example is applications that control access based on Active Directory (AD) accounts and Active Directory Security Groups.  While Active Directory may be the most common example, other vendors offer products and solutions that make authentication (is this person really Bob?) and authorization (can Bob access this resource?) decisions.

Vendors:  Other vendors include Cisco (via the Securent acquisition), RSA Entitlement Policy Manager (EPM), BitKoo, Rohati, Quest (Vintela), and even Microsoft has another technology called Authorization Manager (AzMan).

The Value of Externalizing AAA:  This approach is advantageous to software vendors and developers.  It allows them to concentrate on the core competencies of their application, while relying on the expertise of another vendor for authentication and authorization. While externalizing AAA is powerful, it can introduce complexities in the way that permissions are assigned and audited.

Example:  Let's look at an example that I've experienced as a site owner in SharePoint.  SharePoint has a permissions model that is built on top of Active Directory groups and accounts.  As a site owner, I assign and control access via our corporate AD groups.  The challenge that I have is that I don't have visibility into the AD group membership, so I'm unable to easily figure out who can get to my site at a certain permission level (read versus write).

Sprawl:  The problem grows more complex as more systems (in this case) use AD for AAA.  For example, I just found that our corporate VMware vCenter security model is tied into Active Directory.  The group membership of my corporate account potentially grants me access to both SharePoint and VMware.  In fact, looking across all systems in the enterprise, here's what comes to mind for systems that are using an external system (AD) for AAA:

• SharePoint (over 100 sites)
• SQL Server databases
• Spam Quarantine
• VMware vCenter
• Corporate Intranet
• Citrix License Server
• Citrix Password Manager
• Citrix XenApp
• Windows Shares
• And more....

Challenges:

Visibility:  Given an entitlement in AD (or any other system), it is difficult to determine the systems and resources that it governs.

Unintended consequences: I assign Bob group membership in Grp Y to grants him read access to SharePoint....what else does Grp Y control?  Is Bob also getting access to VMware?

Proliferation: to avoid the unintended consequences above, one might define an AD group per applications.....however, this can lead to a proliferation of AD groups.

Terminology:  "Grp Y" may make sense to a technical person in IT, but it's not intuitive to business users.

Multiple Administrators: Multiple administrators and multiple systems need to be looked at to determine who can get to what. 

• The VMware vCenter Admins can determine which AD groups control permissions in vCenter. 
• The AD administrators can tell you who is a member of the AD group , taking into consideration nested groups, dynamic groups, etc in AD.

Market Needs:  Companies need solutions that provide visibility into the business functions that are assigned to people, rather than the low level IT attributes such as AD group membership.  The IT department is capable of making the connection between the application and the externalized AAA system (such as Active Directory).  Business users often cannot make the connection and hence don't have the visibility to fully understand the business functions assigned to workers.  Ideally a business would manage the assignment of permissions in terms of the application in a single step (Ex: Make Bob a Power User in VMware vCenter).  At the time of assignment, you could see the other business application permissions that would be carried along with the change (unintended consequences).  At any point, you could look at the infrastructure from the perspective of a person, a system, or an application permission to get the full picture of who is assigned which permissions:

• Connect a person to permissions in various systems
• Look at a system, view all permissions for all people
• Look at a permission on a system, determine people who have it assigned
• Look at the AD group (AAA resource) and determine what it controls (systems) and who has access (people)

With these capabilities in place activities such as assigning and managing access are simplified and the business has visibility into who is assigned which kind of access.