Authorization Service
The Authorization Service provides consumers with an access control system for the Team Foundation Server. You can use the Authorization Service to register securable objects. You can grant, deny, or check permissions on those objects. Authorization Service is the preferred method of control for other Team Foundation services. However, consumers such as the Version Control service can augment this system by implementing their own authorization logic. Although consumers can implement custom authorization logic, you should still use the Group Security Service for resolving group membership queries to enable centralized administration of identities for Team Foundation Server.
Invocation
The invocation in the following section instantiates a new Authorization Service from the Team Foundation Server API.
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Server;
...
TeamFoundationServer tfs = null;
string serverName = "My TFS";
tfs = TeamFoundationServerFactory.GetServer(serverName);
tfs.EnsureAuthenticated(new UICredentialsProvider());
s_IAuthorizationService = (IAuthorizationService) tfs.GetService(typeof(IAuthorizationService));
...
If you cannot execute a method successfully, the system throws an exception.
Securable Objects Classes and Actions
Every object to be secured on the Team Foundation Server must have a unique string identifier and must belong to an object class. The following method lists all available object classes for Team Foundation Server.
string[] ListObjectClasses()
There is a predefined set of actions available on every object class. You can use these methods to view Programmatic Action names and localized friendly action names for each object class.
string[] ListObjectClassActions(string objectClassId)
string[] ListLocalizedActionNames(string objectClassId, string [] actionId)
Note that the localized names depend on the localization of the server.
Registering Objects
To create a new securable object, use this method to register the object:
RegisterObject(string objectId, string objectClassId, string projectUri)
Note that the object is registered by using objectClassId, which is a unique objectId, and a parent team project specified by projectUri. If projectUri is null, the object is scoped globally to the server.
Every securable object in the system must be uniquely identified by an immutable string identifier. This identifier is used in all authorization calls.
Many items on the Team Foundation Server have unique URIs that can be used for the object ID. For other objects, a GUID should be generated and used as the identifier.
Objects can be scoped to the server or to a team project.
You can use this call to identify the class of an object:
string GetObjectClass(string objectId)
When an object no longer has to be secured, unregister it as follows.
void UnregisterObject(string objectId)
Setting Access Control Entries
Access control entries (ACE) are associated with securable objects to grant or deny permissions to users on that object. The collection of ACEs on an object is referred to its Access Control List (ACL).
An ACE is defined as follows:
AccessControlEntry
string ActionId One of the actions defined by the class to which that the object belongs
string **Sid ** Identity that is granted or denied the permission
bool Deny Set to true for DENY ACEs, and to false for ALLOW ACEs
bool Inherited Indicates that the ACE is inherited from another object
Access is denied unless granted explicitly (that is, an empty ACE means DENY ALL).
void AddAccessControlEntry(string objectId, AccessControlEntry ace)
void ReplaceAccessControlEntry(string objectId, AccessControlEntry [] acl)
void RemoveAccessControlEntry(string objectId, AccessControlEntry ace)
Use the previous methods to add, replace, or remove the ACEs for a securable object. Use the methods in the following section to view the ACLs for securable objects.
AccessControlEntry [] ReadAccessControlList(string objectId)
public AccessControlEntry[][] ReadAccessControlLists(string[] objectId)
ACL Inheritance
The authorization service allows ACL inheritance from objects of the same class. If object X inherits from object Y, ACEs on Y are merged with ACEs on X. The result set is used for permission evaluation. Chained inheritance is supported. For example, inheritance passes from object A to B to C. For objects that have inherited permission, DENY entries override ALLOW entries.
Use the ResetInheritance method to set up inheritance between an object and a parent object.
Authorization
Whenever you request a privileged action on an object, you should use the CheckPermission and IsPermittedBySidList methods to authorize it correctly. Third-party plug-ins or applications are responsible for explicitly calling these methods before permitting users to take an action against a secured object.
Special Cases
If a user is a member of an administrative application group, permissions on certain objects may be granted regardless of DENY entries.