Define and enforce access control policy

When fully adopting the concepts around federated authentication and authorization - e.g. as driven by Safewhere*identify with the Safewhere*authorize addition - a natural next step is to define and enforce access control in terms of the attributes - or claims - issued during login.

This is exactly what Safewhere*protect does. The product has to main components, namely a central access control policy authoring and distribution server, and a range of "protection" agents to actually enforce defined policies.

Safewhere*protect Policy

• This is where you define access control policies to primarily web sites and services. Note in particular that Microsoft SharePoint represent a special case, as it does not require an external policy to be defined as SharePoint already employs its own system for access control. (See more on SharePoint further down)

Safewhere*protect Enforcement

• Safewhere*protect for SharePoint is a feature for Microsoft SharePoint enabling the definition of richer, attribute based, permissions instead of the traditional RBAC model built into the product. With this feature, you may set permissions expressing that you must "be from a given organization, 2-factor authenticated, and have entitlement XYZ" to be granted the right to edit a document.
  To learn more about the challenges with SharePoint, read our white paper on dynamic access control in SharePoint
• Safewhere*protect for Web and SOA is a set of Microsoft .NET (ASP.NET and WCF) assemblies, Java servlets or Apache Axis2 plugins to enforce access control outside of applications and services. This feature basically intercepts requests, picks out the embedded user token, and compares its attributes to those required by the Safewhere*protect access control policy.

As access control is enforced at the actual resource with no way around it, audit logs may be kept and consolidated across the infrastructure for subsequent inclusion in compliance documentation.