Authorization Services (RBAC)

Claims and Role-Based Access Control for Enterprise Wide Security

Enterprise Wide Role and Claims-Based Access Control

Keeping up with compliance and audit requirements for the multitude of diverse enterprise directories and applications used by today's organization is a costly challenge. What is needed is a platform that unifies visibility, audit control, and enforcement over all enterprise systems within a single security model.

The Dot Net Workflow platform solves the challenges and eliminates the problems encountered with typical RBAC implementations by providing a flexible claims and RBAC model that dramatically simplifies the entire process. Rather than requiring months of planning and deployment, the Dot Net Workflow platform allows you to immediately enjoy the benefits of RBAC with a non-disruptive process that supports continuous improvement and optimization. By using a uniquely powerful and flexible framework comprised of Business Roles, Locations, Management Roles, and Resource Roles, EmpowerID and the Dot Net Workflow platform brings easy role-based identity and access management to your business.

Dot Net Workflow authorization services offer a robust platform for the granular control and audit of enterprise security for legacy and claims aware applications.

Rights-Based Approval Routing (RBAR)

The greatest security challenge for workflow automation is the disconnect that occurs between the security sensitive actions executed in a workflow and the actual security delegation policies that determine who may perform these actions and against which specific objects they may perform them, as defined by the security system of record. The Dot Net Workflow platform closes this gap through the transparent enforcement of delegation policies through the inherent security of the workflow architecture, without requiring any specific modifications to accommodate the security. In fact, designing a secure workflow does not require knowledge of the security mechanism by the workflow's designer. This permits accelerated secure workflow and application design that has not been possible with workflow products until now.

The Dot Net Workflow platform's default workflow approval routing mechanism, called Rights-Based Approval Routing (RBAR), routes requests based upon delegation of protected actions, called operations. Operations are workflow shapes that represent protected code actions that can be delegated using role assignments. These special operation workflow shapes contain a miniature authorization and approval workflow inside of them, called the operation approval base. This hidden (embedded) workflow is shared by all operations of the same type and provides a real-time authorization check that determines whether a person attempting to execute an action against a resource has a role that allows them to do so. If the current person does not have the required rights, the mini workflow handles any approval routing, creation of task tracking dashboard entries, and email notifications.

The operation shapes that ship with EmpowerID are created in Workflow Studio, which provides wizards to create new operation shapes from custom code, web services, PowerShell cmdlets and more. Workflow Studio also allows the embedded authorization workflows that are contained inside each operation shape to be modified or extended, which gives an organization the ability to customize the default approval routing mechanism for all secure actions.

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.

Flexible 3-Tier Role-Based Access Control Model

The Dot Net Workflow platform offers a scalable RBAC metadirectory that supports both newer applications that can leverage an external authorization source as either a claims source or a .NET Membership and Role Provider, as well as older applications that store and manage all permissions inside the applications themselves. For these legacy systems, the sync engine pushes permissions assignments into the systems based upon centrally stored authorization policies.

The Dot Net Workflow RBAC metadirectory inventories the native permissions from managed systems for audit and reporting purposes and provides a controlling RBAC model that can be used to dynamically manage and enforce the permissions in these systems. The RBAC model is made up of three tiers to both represent the native permissions stored in applications and to provide an overarching layer used to automate permissions assignments based upon business policies and information derived from authoritative sources like HR and ERP applications.

Technical or Application Roles: "Resource Roles"

A Resource Role is an application or resource type-specific definition of a set of rights that make sense for a particular system. For example, consider the Contributor role in Microsoft SharePoint. Within SharePoint, membership as a Contributor is meant to convey a specific level of access in that application. In Dot Net Workflow, Resource Roles allow for the seamless migration of that native meaning to RBAC by allowing for the discovery of existing users' permissions for resources and the mapping of their user accounts to these Resource Roles.

Functional Roles: "Management Roles"

Management Role Definitions, and the child Management Roles that are derived from them, are job or responsibility-based bundles of Resource Roles that allow for the quick and consistent delegation of IT resources to users, based upon their function within an organization. A Management Role Definition allows you to create a baseline for granting access to resources by job function, which can then be tailored into individual Management Roles to fit any number of different implementations of that definition within an enterprise.

As an example, system administrators could create an "IT Helpdesk" Management Role Definition that delegates access to all of the EmpowerID pages, workflows, and resources generally needed by all IT Helpdesks within an organization, and then use that definition to create individual Management Roles, such as an "IT Helpdesk Europe" or an "IT Helpdesk Americas" that delegates access to the specific resource needed by those specific helpdesks. Using this model, access to all of the pages, workflows, and applications, etc., could be assigned at the Management Role Definition level while specific regional access to manage the geographically diverse users, mailboxes, groups, computers, SharePoint, and other types of resources would be assigned specifically to the related IT Helpdesk Management Roles.

Business Roles: "Business Roles and Locations"

Dot Net Workflow's RBAC uses a polyarchical model that provides a flexible framework for assigning Resource Roles and Management Roles, solving many of the traditional challenges encountered when implementing RBAC. This unique approach allows access to resources to be based upon the combination of what a person does in the organization (Business Role) and where they work (Location), as defined statically or based on an external authoritative source such as an HR system. This enhancement to RBAC dramatically reduces the number of roles required in situations where employees with the same job title (e.g. Bank Teller) working in many different locations need access to many of the same resources as well as others that vary based upon location. Without this dual assignment model, a Bank Teller Role would need to be created for every possible bank location. This "role bloat," typical of other systems, reduces the value of RBAC and dramatically increases complexity and the amount of manual work required by a system.

Claims-Based SSO and Authorization

The Dot Net Workflow platform offers a standards-compliant Federation Server (Security Token Service) supporting the SAML, OpenID, and WS-Federation protocols. Externalizing application security to a standards-based authorization server enables organizations to remove identity logic from their application, improve developer productivity, enhance application security, and enable interoperability. The Dot Net Workflow Federation Server is designed to provide full support for OpenID and SAML as well as deep support for the federation technologies found in Microsoft ADFS 2.0 and SharePoint 2010.

In a federated security model, authentication is performed by a Security Token Service (STS) that issues security tokens containing claims. Claims are statements of fact about the identity and access rights of the authenticated user. Users can be authenticated in any trusted directory while being granted access to applications and services belonging to other organizations where a trust relationship has been established. This new model removes the need to remember multiple usernames and passwords and allows security management to be centralized.

The claims granted to users in a federated model allow applications to authorize access to features and functionality based on claims from issuers (the STS) in trusted domains. Claims can contain information about the user, roles or permissions, making it a very flexible authorization model. The Dot Net Workflow platform uses claims for its own internal security and provides claims for use by other applications like Microsoft SharePoint 2010. The federated security model is extremely flexible and opens up new avenues for controlling access to application resources. Permissions can be managed in external systems such as the Dot Net Workflow platform and need not be hard coded in an application with federated security.

Group to Protected Resource Linking

The key challenge in any strategy for centralizing the management of application and resource permissions using AD or LDAP groups is the absence of an auditable link between the groups granting the access and the application permissions they grant. As a result, AD and LDAP Groups can quickly become a black hole for compliance initiatives. Organizations will often use complex group naming standards in an attempt to "relate" groups to the resources they protect, but this method is not secure or auditable. EmpowerID addresses this need by extending the capabilities of AD and LDAP groups by mapping groups to the resources they actually protect. This creates a more intuitive experience, allowing end users and IT auditors to see who has access to which applications and resources in addition to who is a member of which group. Access requests are also more intuitive, for instance: users may request access to file shares, Exchange shared mailboxes, SharePoint sites, and even custom applications directly, without needing to know which groups control their access.

Why Dot Net Workflow Authorization Services

Dot Net Workflow provides a modern RBAC and claims-based hybrid model to deliver a flexible enterprise solution for authorization management that you won't outgrow.

  • Role-Based Access Control - A sophisticated enterprise proven Role-Based Access Control model with three tiers of roles for granular delegation and reporting of who has access to what
  • RBAR - Rights-based workflow approval routing
  • Metadirectory structure designed to store and represent rights and roles from other systems
  • Enforcement of permissions into legacy systems that do not support external authorization
  • External authorization and single sign-on for claims aware applications
  • Reporting and audit from all perspectives and activity tracking
  • Group to Resource Linking - Allows access requests and auditing to be more accurate and intuitive by displaying the actual resources protected by groups