Archive for June, 2011

Security overview

June 2, 2011 Leave a comment

1. Terminology.

In order to describe common security concepts, different companies use various notations.  I will use Microsoft definitions in this overview. The best way to bring clarity and understanding into this complicated topic is to follow the evolution of security concepts.  Every organization which decides to develop custom security framework has to carefully review the lessons of that past to scope requirements and plan an implementation.

1.1        Permissions, Roles, Users, Groups and Scope.

The original idea of securing access to the resource could be described as a process of establishing relationships between Requestor or Principal and the Object or ACE (Access Control Entry).  In order to achieve this goal, ACE has to define a set of operations (permissions) that a potential Principal could perform with the object.  The subset of operations available to the Principal is called the ACL (Access Control List). The principal with no ACL would have no access to an object. The ACL with the full permissions set has a special name – Full Access.  A good example would be a File object (ACE), with Read, Write, Delete, Create, Move permissions set and Yuriy G. as a Principal with Read, Write ACL.

The change of this concept came as an answer to administrator’s question of how to manage the ACL between the principals and the objects. The simple example, which includes 100 users and 100 objects of the same type with 6 operations each, will create a 60,000 permutations nightmare.  The solution was to group principals and permissions. The group of principles is called simply “Group” and group of permission is named “Role”. This simplification lets administrator use the group as the principle, and to map it to the role with already defined ACL(s).  For example – Administrators, Developers and Business Analysts groups of users mapped to the Full Access, Contributors, and Readers roles respectively.  Applying this concept to the above example will reduce the number of permutations from 60,000 to 9.


1.2        Authentication and Authorization

Authentication is a process of identifying the user within the security store.  If a user exists, the system issues the authentication ticket. A requestor that does not exist in the security store is mapped to an Anonymous account (ASPNET/IUSER_MACHINENAME for IIS or Guest for NTLM).

Authorization builds the ACL in the form of permission sets or Roles list. Authorization happened only for authenticated users. Remember that Anonymous user, if not disabled, is a valid Principal with all associated permissions.

1.3        Single Sign-On

Single Sign-On is a run-time mapping process between two Principals located in two different security realms. The user story for SSO would be a request to login once in one system and gain access to another system without being prompted to login again. Behind the scene, the SSO server process takes provided credentials as a key to find credentials for targeted system.

2. Security System design principles.

The security system has to be clear, well understood, easy to administer and monitor. The different security providers have to expose the same contract in common terms to avoid confusion between security consumers.  The implementation has to consider a possibility of reusing existing mature security frameworks.

2.1 Grouping  user and permission

Grouping users and permissions plays essential part in the security system design. The rule of thumb is never map (ACL) user to the resource permission directly. Always create groups and   roles and establish relation between them.  There are several standard questions need to be answered before implementing the security system:

–  is users permission set will be inclusive or exclusive if user is a member of multiple groups.

– the granularity of  permission set.

–  what type of users application in question supports.

I don’t have strong opinion about the what would be resulting calculation of the permission set for the user which belongs to the multiple groups either it is union of all permission  or interception of them. The important part is to stick with the decision made.

The granularity is very depends on an application. Usually,  for ASP.NET application the Role – group of permissions is just an abstraction with no permission attached. The authorization steps relies on the application logic. For more advanced scenarios permission  could be grouped in operations , operations in  task and task in roles. The trivial example would  be file permissions.   The  permission set for a file resource  are  Read, Write , Create, Delete. The Tasks could be : View (Read) , Modify(Read, Write), Move(Create,Delete) , Full(Read,Write,Create,Delete). Finally Roles could be Administrator Role(Full) ,Contributors(Modify, View), Readers(View).  In the end what administrator does is map Administrator Group to the Administrator Role, and the Group of external users to the Readers. The management of the users and their membership completely decoupled from the managing Roles.

The last question is also specific to an application. There are two types of users: application users and Network users. Application users are users that are not recognizable by the network and their identity store in the custom security store. Network user identity stored in the network security store. If application meant to deal application and network users, it would be good idea to use the security store which supports both types such as AzMan.


2.2 Zoning 

With the emergence of the Enterprise systems with numerous organization topologies and application deployment scenarios it became obvious that instead of trying to manage entire enterprises it would be easier for administrators to define zones within it and manage every zone independently. This process is called scope reduction or zoning. This paradigm allows using multiple security models, and forces the principle to specify scope prior to the authentication process.

The good example of zoning is the domain we specify during the login.

Technically speaking the Domain1\Yuiry and Domain2\Yuriy are to completely different principals   coming from two independent security stores and unauthorized access is prevented on authentication step. The very important part to understand that in case of using single zone/domain/realm any user located in the security store will be authenticated without establishing association to the party, company or application. This association is left to the Authorization step and completely relies on the application logic.  In some cases, in order to resolve dependencies, an application issues custom queries against a security store outside of the security framework.  The design concepts and entity model within the framework become not clear and prone for security hacks.




3.1 Active Directory

Active Directory is a comprehensive security store for internal users.  It supports Authentication and Authorization, user and permission grouping and zoning. Also, it has a built-in administration and monitoring.   AD administrators usually delegate application specific authorization to the application owners. It allows them to choose the Role definition store technology.  It would be advisable to take into consideration SQL database or AzMan.

3.2 ADAM –Active Directory Application Mode.

ADAM is light-weight active directory with ability to store external users and references to internal users. It supports authentication, authorization, scope reduction, delegated administration and monitoring. It is integrated with AzMan (Authorization Manager) role store.

3.3 ASP.NET framework extensions.

ASP.NET security is developed on top of ASP.NET 2.0’s pluggable authentication provider model and has custom Membership Provider implemented for user authentication and custom Role provider for user authorization.  It supports user grouping and some advanced scenarios (group within a group). It has an Administration console implemented, but doesn’t support delegated administration.

3.4 Microsoft Sql ASP.NET security framework extensions.

This is the built-in Microsoft implementation of ASP.NET provider model. It supports authentication, authorization and scope reduction. Membership provider does not support user grouping. It has a very simple administration console.  It allows quick application integration into a security framework, well tested and widely understood. This implementation does not support zones. Any user located in the security store will be authenticated without establishing association to the party, company or application. This association is left to the Authorization step and completely relies on the application logic. In some cases, in order to resolve dependencies, an application issues custom queries against a security store outside of the security framework.

3.5 SharePoint security framework.

SharePoint has a comprehensive and flexible security model which is based on ASP.NET 2.0 security framework. The ability to specify different providers per web application and zone allows support for administration, authorization and scope reduction for internal and external users. SharePoint allows delegate security administration to the external users. SharePoint also supports single sign-on, portal configuration and item based security.


3.6 Windows Identity Foundation (WIF)

WIF is  a new Microsoft framework  used to build claims-aware and federation capable applications, externalizes identity logic from their application, enhancing application security, and enabling interoperability. This

Categories: Security Tags: