ABAC Building Block Flow Diagram

1 post / 0 new
skinling
ABAC Building Block Flow Diagram

The NCCoE welcomes questions and comments on the below flow diagrams and accompanying description, which elucidates some of the initial work under the ABAC building block. 

SCENARIO 1 – Enterprise to Enterprise Identity Federation and Access Control

1) SCENARIO DESCRIPTION

An airline with operations in the western United States, Runabout Air, wishes to expand service coast to coast. Instead of purchasing additional airliners, Runabout Air has acquired Conway Airlines which has existing service in eastern United States. The merger will require the integration of several IT systems including operations, financial and sales.

Runabout will have an immediate need to give IT systems access to Conway employees. An analysis of IT systems from Runabout and Conway has concluded the quickest way to allow the two companies to utilize each others resources is by establishing a trust relationship between the two organizations identity management systems. To accomplish this, runabout will implement a federated identity system where Runabout resources accept secure authentication tokens from an existing Conway identity and access management (IDAM) system. This will avoid costs associated with replicating user repositories across both enterprises. Additionally, Runabout will use existing business rules to determine access permissions for Conway employees based on attributes from the Conway IDAM system. As a result, Runabout and Conway will enhance their security postures by implementing consistent policy across the enterprise.

2) BUILD CAPABILITIES

This initial build seeks to demonstrate the following capabilities:

• User Authentication and the creation of an authentication context in the form of environmental attributes collected at the time of authentication
• Federation of an authenticated user identity, subject attributes and environmental attributes (to include authentication context) between an identity provider and a relying party.
• Implementation of a XACML based policy enforcement and decision point that will externalize access decisions for a Sharepoint instance. 
• The creation of attribute based policy definitions.
• At the time of resource access, the ability to collect subject, object and environmental attributes that are subsequently used to make access decision based upon the attribute values.
• The ability to request additional attributes from the IDP, should insufficient attributes be presented when making an access decision.

3) THE TECHNOLOGY

The UML sequence diagram for this first build of Scenario 1 is shown in two parts, 1A and 1B.   Shown on the left side of the UML is the Relying Party (RP) or Runabout Air in the above description with its SharePoint system containing strategic corporate resources that users from the enterprise on the right side, known as Conway Air in the above, wish to access.  In this scenario, Conway Air acts as an Identity Provider (IdP) federating authentication and attribute assertions to the Runabout. Runabout, relying upon its established trust relationship with Conway, is able to use these assertions to make access decisions on Conway employees, even if the employee has never had an account provisioned by Runabout’s IT staff.

In this build, OASIS SAML 2.0 serves as the core federation technology, with the actual federation exchange being the SAML “Web Browser SSO Profile”, implemented in an RP-initiated manner.

In the scenario depicted in UML 1A, the unauthenticated user first tries to browse directly to a resource at the Microsoft SharePoint installation. For the purposes of this build SharePoint’s native access control capabilities are supplemented with the capabilities NextLabs Entitlement Management and Control Center product line which offers fine-grained access control (FGAC) based on the OASIS XACML standard.  In XACML parlance the NextLabs entitlement manager provides an additional operational layer to SharePoint of in the form of a policy enforcement point (PEP), while the control center acts as the policy decision point (PDP) and policy administration point (PAP).

If the user is not authenticated when making their first access attempt the UML shows redirection or a call back to the Ping Identity PingFederate-RP system. Since SharePoint has built-in access control and is claims aware, it natively supports the use of WS-Federation and SAML 2.0 to complete the home realm discovery process that is kicked off by this call back. In this case the PingFederate-RP functions as a trust broker specifically for the SharePoint target resource, but in typical enterprise it may perform this capability for other target systems as well.

For this build the PingFederate-RP is shown supporting two options for resolving the need for obtaining additional user information of authentication and attributes. 

1. A SAML authentication request and/or a SAML attribute request that PingFederate-RP makes to the user’s IdP.  In this UML diagram there is only one IdP to select from. There may be a separate flow to handle the case for multiple IDPs in the future.

2. When SAML responses are received by the PingFederate RP, accounts can be provisioned and attributes can be stored in a just-In-time (JIT) cache at the RP.  If the user’s identity is known (i.e., passed from SharePoint or the NextLabs PDP) a call can be made to the JIT cache for attributes. In this case, a polling function over the SCIM protocol will be ensure identities in the JIT identity store are not stale.

The federation system on the identity provider (Conway Air) side of this build includes a second separate instance of the Ping Identity PingFederate-IdP.  It receives a SAML requests for user identity and/or attributes, and provides a response.  PingFederate-IdP supports multiple types of direct user authentication, as shown in the UML, and it also supports retrieval of subject attributes by various means. This build uses LDAP to access an IDP identity store (which could be Microsoft’s Active Directory) when retrieving subject attributes.

In addition to subject attributes, the PingFederate-IdP works closely with RSA’s Adaptive Authentication (AA) to gather addition information about the user and the context in which the user is authenticating. This integration is handled by the SCE group’s adaptive authentication plug-in which helps guide the AA sequencing shown in the UML. In order to gather the appropriate context, the AA system gathers “facts” and “predictors” about the user and their environment at the time of authentication. These facts and predictors are then analyzed by the AA system and a decision is made on whether the particular context of user attributes, target resource attributes, and user environment are such as to require an additional authentication step, known as step-up authentication. 

Once the user has been authenticated, PingFederate-IdP returns to the RP trust broker (PingFederate-RP in this case) a SAML response that includes the set of user attributes and the authentication context, comprised of environmental attributes gather by RSA’s AA. Once the SAML response has been received by PingFederate-RP, it may provision an account and store attributes in a just-in-time manner.

PingFederate-RP, as the RP’s trust broker, will then pass assertions to the target SharePoint application as claims, where they are accessible by the NextLabs PEP. When the user makes an access request, the NextLabs PEP will trap it and send any subject, object and environmental attributes needed to make an access decision to the NextLabs PDP. If the PDP has the required attributes to make a decision, an allow or deny is sent back to the PEP.

Optionally, the PDP can request additional attributes. If this is required, the PDP will initiate a secondary SAML attribute request at the PingFederate-RP. This is done using the NCCoE policy information point plug-in, which allows the PDP to initiate the request with the PingFederate-RP.