1. 3190 StarTeam Security Explained!
Ron Sauers
Principal Architect
Borland Software Corporation

2. StarTeam Security?
Help prevent unauthorized access to a StarTeam server by requiring strong passwords.
Use an encrypted connection to secure data as it moves across the network.
Grant or deny access to the assets stored in the repository.

3. StarTeam Security Security Model Access Test Algorithm Myths
A New Model
StarTeam SDK 2005
Best Practices

4. StarTeam Security Model

5. StarTeam Security Model
Access Rights
Access Control List
Access Control Entry
Privileges
Ownership

6. Access Rights
Permissions that may be granted or denied to a specific user or group.
Some are generic, and apply to any type of object (e.g., “See an object and its properties”).
Others apply only to objects of a specific type (e.g., “Check in file”).

7. Access Rights
Permission.
GENERIC_SEE_OBJECT
FILE_CHECKIN
. . .

8. Access Control List
Describes how access rights are granted and denied to users and groups.
An Access Control List (ACL) is a list of Access Control Entries (ACEs).
The order of the ACEs in an ACL is significant.

9. Access Control List Java: ACE: class AclEntry ACL: AclEntry[] .NET:
ACE: class ACE
ACL: class ACL

10. Access Control Entry

11. ACEs in the SDK
// true for a "Grant" ACE; false for a "Deny" ACE.  public boolean isGranted();    // The User or Group for which rights are granted or denied.  public int getID();    //true if the ID is a Group ID; false if the ID is a User ID.  public boolean isGroupID();    // The access rights that are granted or denied to this user  // or group, as a bit mask.  public int getPermissionFlags();

12. ACLs and ACEs

13. Types of ACLs
Object-Level ACL
Container-Level ACL
Component-Level ACL

14. Object-Level ACL An ACL that is explicitly assigned to a given object.
You can assign one to the object underlying any Item (File, ChangeRequest, etc.), or to any Project, View, Folder, PromotionState, Filter or Query.
Access rights assigned to an object apply to that object only.

15. Object-Level ACL

16. Object-Level ACL

17. Object-Level ACLs in the SDK
// Returns the object-level ACL assigned to this object,  // or null if this object does not have an object-level ACL.  AclEntry[] getACL();    // Sets the object-level ACL for this object.  public void setACL(AclEntry[] acl);

18. Container-Level ACL
An ACL that applies to objects of a given Type (e.g., File or ChangeRequest) within a given container (e.g., Folder, View or Project).
ACLs may be assigned at any level of the StarTeam containment hierarchy.
The ACL found closest to a given object in the containment hierarchy is the one that applies to that object.

19. Container-Level ACL

20. Object-Level Folder ACL

21. Container-Level Folder ACL

22. Container-Level ACLs in the SDK
// Returns the container-level ACL for objects // of the given type, or null if there is no such // container-level ACL. AclEntry[] getContainerLevelACL(String typeName);   // Sets the container-level ACL for objects // of the given type. public void setContainerLevelACL( AclEntry[] acl, String typeName);

23. Component-Level ACL
An ACL that applies to a StarTeam component (e.g., to the Files component or the Change Request component).
Currently supports access rights on Filters and Queries.

24. Component-Level ACL

25. Component-Level ACL

26. Component-Level ACLs in the SDK
// Returns the component-level ACL for this type, // or null if this type has no component-level ACL. AclEntry[] getComponentLevelACL();   // Sets the component-level ACL for this type. public void setComponentLevelACL(AclEntry[] acl);

27. Group Privileges
Global access rights that are always granted to members of a specific group.
Override other access rights specified for individual objects or containers.
StarTeam Administrators are typically granted special privileges.

28. Group Privileges

29. Group Properties Dialog

30. System Policy Dialog

31. Group Privileges in the SDK
// Gets privileges granted to members of this group.
public int getPermissionsFlags();   // Returns true if members of this group // are granted the given privilege.  public boolean hasPermission(int permission);   // Grants the given privilege to members of this group. public void addPermission(int permission);   // Revokes the given privilege. public void removePermission(int permission);

32. Ownership Most StarTeam objects have an owner.
The owner is automatically granted full access rights.
The actual owner of an object is not displayed anywhere in the StarTeam user interface!

33. System Policy

34. Security Model

35. StarTeam Access Test Algorithm

36. The StarTeam Access Test Algorithm
To determine whether or not user U has access right R for a particular item I of type T …
Test Privileges
Test Ownership
Find the Relevant ACL
Test the ACEs in the ACL

37. Step A: Test Privileges
1. Check the value of the “Ignore group privileges” System Policy option. If this option is set, then skip the group privilege tests.  
2. For each group G of which the user U is a member, check to see if G has been assigned the privilege R. If so, then the access test succeeds, and U is granted access.  
3. Otherwise, group privileges do not apply. Continue.

38. Step B: Test Ownership
1. Check the value of the “Ignore object ownership” System Policy option. If this option is set, then skip the ownership tests.  
2. If U is the owner of the object referenced by I, then the access test succeeds, and U is granted access.  
3. Otherwise, object ownership does not apply. Continue.

39. Step C: Find the Relevant ACL
Check for an object-level ACL associated with the ObjectID of I. If found, then it is the relevant ACL.  
Otherwise, check F, the parent folder of I, for a container-level ACL for objects of type T. If there is one, then it is the relevant ACL.  
Otherwise, search up the folder hierarchy. If F has a parent folder, then repeat step 2 with F = F’, the parent folder of F.  

40. Find the Relevant ACL …
Otherwise, check the View for a container ACL for objects of type T. If there is one, then it is the relevant ACL.  
Otherwise, check the Project for a container ACL for objects of type T. If there is one, then it is the relevant ACL.  
Otherwise, then there is no relevant ACL. The access test succeeds, and U is granted access.

41. Step D: Test the ACEs in the ACL
For each ACE in the relevant ACL …
If the ACE does not apply to U, then skip this ACE.
If the ACE does not specify access right R, then skip this ACE.
If the ACE is a “Grant” ACE, then the access test succeeds, and U is granted access.
If the ACE is a “Deny” ACE, then the access test fails, and U is denied access.

42. Test the ACEs in the ACL …
If no ACE in the ACL applies to both U and R, then the access test fails, and U is denied access.

43. StarTeam Security Myths
Common misconceptions regarding the StarTeam Security Model.

44. Myth: Access rights can be assigned to an item.
You are actually assigning access rights to the underlying object that is referenced by the item.
Access rights affect not only the selected item, but also any other items in its share tree that have the same ObjectID.
When an item branches, the ObjectID changes!

45. Myth: If you don't explicitly specify an access right, it is granted by default.
This is true only in the rare case when there is no relevant ACL.
Be particularly careful when setting access rights via the StarTeam SDK. An empty array and a null ACL are very different.

46. Myth: If you don't explicitly specify an access right, that access right is inherited from the parent container.
There is at most one ACL that is relevant in any given context.
There is never any attempt to somehow combine two ACLs when performing an access test.

47. Myth: You can determine whether a given access right is granted or denied by looking at the Access Rights dialog.
The Access Rights dialog shows only those access rights that are explicitly specified on the selected object.

48. A New Look at Access Rights
Is there an alternate model we might use to help better understand access rights?

49. The Effective ACL
Gather all of the information that is relevant to determining the access rights for a given item.
Represent it in a single, self-contained Effective ACL.
Testing the ACEs in the Effective ACL gives the same results as the full access test algorithm.

50. Explicit and Implied ACEs
Explicit ACE - explicitly stored in an ACL somewhere in the StarTeam repository (from an object-level ACL or container-level ACL).
Implied ACE - represents security-related information that comes from somewhere outside the relevant ACL.

51. Implied Privilege ACEs
Test Group Privileges:
For each group G of which the user U is a member, check to see if G has been assigned the privilege R. If so, then the access test succeeds, and U is granted access.
Group privileges are represented in an effective ACL by including an implied ACE for each group that has been granted privileges.

52. Implied Ownership ACEs
Test object ownership:
If U is the owner of the object referenced by I, then the access test succeeds, and U is granted access.
Object ownership is represented in an effective ACL by including an implied ACE that grants full access rights to the user who is the owner of the object.

53. Implied Deny ACEs When there is a missing ACE in the ACL:
If no ACE in the ACL applies to both U and R, then the access test fails, and U is denied access.
Access rights are completely specified if there is some explicit ACE in the ACL that either grants or denies every access right to the All Users group.
Add a single implied ACE to the end of the effective ACL that denies the unspecified rights to the All Users group.

54. Implied Grant ACEs When there is no relevant ACL:
If no relevant ACL was not found, then the access test succeeds, and U is granted access.
Add a single implied ACE to the end of the effective ACL that grants all access rights to the All Users group.

55. An Example

56. Benefits of Effective ACL Model
All security-related information that is relevant in a given context is collected and summarized.
Rules that are implied by the access test algorithm are made explicit.
It is always possible to explain the results of any access test in terms of the effective ACEs that were determinative.

57. Benefits of Effective ACL Model

58. New Features in StarTeam SDK 2005

59. New in StarTeam SDK 2005 ISecurableObject ISecurableContainer
AccessRightsManager
EffectiveACE
AccessTestResults

60. ISecurable interface ISecurable {
// Get/set the object-level ACL.     AclEntry[] getACL();     void setACL(AclEntry[] acl);       // Performs an access test against this object.     boolean hasPermission(int permissions);       // Returns this object's parent container.     ISecurableContainer getParentContainer();       // Returns the type of this securable object.     Type getType(); }

61. ISecurableObject
// A securable object that has an owner. interface ISecurableObject extends ISecurable {       // Returns the userID of the user     // who currently owns this object.     int getOwner();       // Changes the owner of this object     // to the currently logged-on user.     void acquireOwnership(); }

62. ISecurableContainer
// An object that can have container-level access rights. public interface ISecurableContainer {       // Get/set the container-level ACL.
AclEntry[] getContainerLevelACL(String typeName);
    void setContainerLevelACL(AclEntry[] acl, String typeName);       // Performs a container-level access test.     boolean hasPermission(int permissions, String typeName);     // Returns this object's parent container.     ISecurableContainer getParentContainer(); }

63. AccessRightsManager Provides the following new features:
Determine the effective access rights in a given context .
Perform access tests against the effective access rights.

64. AccessRightsManager
// Determines the effective access rights // for the given securable object. EffectiveACE[] getEffectiveACL(ISecurable obj);
// Performs an access test against // the given effective access rights. public AccessTestResults accessTest(int userID,                                      int permissions,                                      ISecurable obj);

65. EffectiveACE // Describes the source of this effective ACE
public boolean isFromGroupPrivileges(); public boolean isFromObjectOwnership(); public boolean isFromObjectACL(); public boolean isFromContainerACL(); public boolean isFromMissingACE(); public boolean isFromMissingACL();
. . .

66. EffectiveACE Provides a human-readable description:
These access rights are explicitly granted to members of the "All Users" group in the container-level Access Control List (ACL) for objects of type Change Request defined for Project “StarDraw”.

67. AccessTestResults Describes the results of an access test.
Indicates whether the requested access rights were granted or denied.
Also provides an explanation for the decision, expressed relative to the EffectiveACEs.

68. AccessTestResults

69. Access Testing in the SDK

70. Simplify implementation and maintenance of access rights.
Best Practices
Simplify implementation and maintenance of access rights.

71. Design with security in mind.
Security requirements are often overlooked when designing the structure of a StarTeam project.
Are there some files that will have different access rights than others?
Are there different groups within the organization that will require access to different subsets of the files?
Changes made early are typically easier to make than changes made to a mature project.

72. Minimize the number of security control points.
Create as few ACLs as possible.
Every ACL is critical project data that must be maintained over time.
A project that has one container-level ACL for objects of type File is much easier to manage than a project that has a separate object-level ACL for every file.

73. Secure at the container level.
Set access rights at the container level whenever possible.
This is especially true for items within a Folder.
It is better to have a container-level ACL on a parent folder than it is to have separate object-level ACLs on each item in the folder.
Container-level access rights should be set as high in the containment hierarchy as possible.

74. Minimize the number of users who can change access rights.
Not all users understand the security model.
Getting it wrong can have serious consequences.
Limit the number of users who have the right to change access rights.
Grant the "Change object access rights" privilege to a single "StarTeam Security Administrators" group.
Never explicitly granted this right in any ACL.

75. Avoid user-specific ACEs.
A user is granted access rights based on his or her role in the project.
It is better to create a Group whose name reflects the role, and assign access rights to that group
Access rights can be updated by changing group membership, rather than by reviewing and updating ACLs.
Handles a growing team, with multiple users filling the same role.

76. Avoid ACLs on items that branch.
Access rights are assigned to the underlying object that is referenced by the item.
Two items with the same ObjectID necessarily have the same object-level ACL
Two items with different ObjectIDs have independent ACLs.
When an item branches, it gets a different ObjectID.
Avoid ACLs on Folders that might branch.

77. A Problem Scenario
Create FolderA. Assign a container-level ACL with the required access rights.
Create a branched view for a parallel development stream. The branched view also has a reference to FolderA, with the same objectID and ACLs.  
In the parallel development stream, rename FolderA to FolderB. FolderB has a new objectID, and no longer shares ACLs with the main view.

78. A Problem Scenario
Anyone changing the properties of a Folder that has assigned ACLs must be aware of the implications with respect to security.
Whenever assigning object-level or container-level access rights to a Folder, ensure that only security administrators are granted the "Modify properties" access right.

79. Use sharing when it simplifies the implementation.
Conflicting requirements can complicate the access rights implementation.
Assign a container-level ACL to the folder, and override with object-level ACLs on selected files?
Avoid object-level ACLs on individual files.
Create a separate folder with alternate ACL.
Share items between folders.
Do not branch on change!

80. Consider disabling the object ownership feature.
Owner of an object is automatically granted full access rights.
Owner of an object is not displayed anywhere.
Consider disabling the object ownership test in the System Policy dialog.
Is there a user who should be granted full access rights? Design that into the project.  

81. Questions?

82. Thank You Please fill out the speaker evaluation
3190
StarTeam Security Explained!
Please fill out the speaker evaluation
You can contact me further at …