Saturday, October 18, 2008

Implementing Sharepoint security

There are two major approaches to implementing Sharepoint security:

1. AD groups
Create Active Directory groups for each site collection and optionally each subsite and object that will require unique permissions. Create a new SharePoint OU (Organizational Unit) within Active Directory. Put these new groups in this OU. Then add these groups to their corresponding SharePoint groups in SharePoint (Owner, Member and Visitor). Adding users to the AD groups may also be done through an externa identity management application.

Advantages: Control, as all changes to security happen in Active Directory. It is easy to add/update/delete people from groups. No individual user accounts are stored in SharePoint with regards to security.

Disadvantages: Extra setup work. Each site you create a new site collection or a subsite/object that requires unique permissions. You have to set up Active Directory first and then add the groups to SharePoint. If your SharePoint administrations and your Active Directory administrators are different people, they have to cooperate.

2. Sharepoint groups
Ignore Active Directory groups and let the SharePoint administrators and site collection administrators add people directly to the groups provided by SharePoint.

Advantages: Easier admin as it lets the SharePoint administrators quickly change security without needing to involve the Active Directory administrators. It's also easier to see the names of everyone that has the permissions for a SharePoint group right from the interface instead of having to go to the Active Directory administrators and having them look it up.

Disadvantages: Maintainability suffers. You can have individual user accounts all over your SharePoint farm and not know who has permission to what. Out of the box, SharePoint does not provide a tool that shows you all the permissions a specific user account has (although there are 3rd party tools that provide this). When someone leaves or you need to move their account between departments, for example, it can be time-consuming to update the permissions in SharePoint.

The first approach is clearly the better practice in my opinion.

External Access/Identity management
With companies setting up external Access management/Identity management platforms, you also need to look into how the Sharepoint security architecture maps into the corporate access/identity management architecture. Typically, You want to use the IdM application to tie users to groups (either AD or Sharepoint groups, both are possible). This way, both internal and delegated administration can be provided. Delegated administration can be offered for extranet partners to manage their own users for instance.

© Copyright 2008, Tomas Elfving

Thursday, October 16, 2008

Security architectures for portal platforms revisited

Do you want to secure more than one application? Manage identities efficiently? This post describes on a high level access and identity management solutions managing the security functions for a portal platform.

This pics shows an RSA implementation, but similar solutions can be set up using any of the leading AM/IdM products:



Identity management
The idea is to centralize the authentification, authorization, administration and delegation of user identities (to create, update, delete and block user accounts) and access control of to user data to a company-wide common platform of reuseable components, instead of doing that in each and every application. For instance, a user’s address may be changed and the identity management solution immediately propagates that into every application and system integrated by the identity management solution. In extranet solutions you may even delegate the user management of a partner company’s users to a superuser in the partner company’s organization by making the identity management solution accessible on the internet (this scenario requires the identity management solution to be used in conjunction with an access management solution).

Separating login methods
Login methods (such as userid/pwd, digital certificates, smartcards etc) may be added to a separate login service. The access management platform ties different login methods to different applications. By choosing this way, you don’t use the built-in security functions of the portal product at all. You trust the access management platform to secure all portal applications. The access management platform may also be used to secure a web services environment in a SOA architecture implementation. Yet another scenario is to secure both an existing web site and a new site during migration.

Web portal application integration
One problem is that editors and developers of web portal applications needs to work in their portal platform (MOSS 2007, for instance) when creating groups and giving access to various resourses of their web application. It might also be complex with rolebased access rights and other fine grained access solutions. You need some interface definition and integration solution between the Identity management solution and the portal platform.

I suggest having the portal platform responsible for creating groups and access rules for resources. The IdM then extracts the groups. In the IdM You add people to the groups which will give them correct access to resources when logging into the web portal application via the Access Management component (which integrates to the IdM as well).

© Copyright 2008, Tomas Elfving