AMS users are assigned to roles based on the operations they are permitted to perform. For example, a business user might be tasked with modifying an artifact, a manager assigned the reviewer role to approve the change, and an IT department member assigned to the administrator role to maintain AMS.

Due to this partitioning of responsibility, each user must authenticate to the AMS web client so AMS can determine the set of operations available to the user. The web client login method passes a user name and password to the AMS and, assuming the credentials are valid, returns a token that identifies the user in subsequent requests, which must include the token. AMS uses a security framework to authenticate and authorize users.

Users are assigned one or more roles, and roles are granted one or more permissions. Each permission specifies an object type, an action that can be performed on that object, and, optionally, a specific instance of the object. For example, the artifact:checkout permission would allow a user with that permission to check out any artifact, while the artifact:checkout:foo permission would allow a user to check out only the foo artifact. The security framework supports multiple security realms (repositories of security information).

Additional permission scenarios:

Grant read access to all artifacts in project P1:

privilege = "artifact:read" 
resource = "P1/*"

Grant write access to all artifacts whose names start with A in projects whose names start with P:

privilege = "artifact:write" 
resource = "P*/A*"

Grant deploy access to all artifacts whose names end with A in all projects:

privilege = "artifact:deploy" 
resource = "*/*A"

As AMS administrator, you define the users who are permitted to log into the AMS web client, as well was what role or roles they play with the projects and artifacts contained therein. Role permissions are configurable.

The following example is a role-to-privilege mappings configuration file with four roles defined:

// RoleToPrivilegeMappings-AMS-example.conf
//
// File that contains the privileges for each AMS role.
RoleToPrivilegeMappings = {

  // Map of roles to permissions
  privileges = {
    
    Administrator = [
        {
            privilege = "*"
        }
    ]
        
    Business User = [
        {
            privilege = "project:import"
        }
        {
            privilege = "artifact:*"
        }
    ]
        
    Reviewer = [
        {
            privilege = "project:approve"
        }
    ]
    AMSDeploy = [
     
        {
            privilege = "artifact:deploy"
            resource = "MyProject/MyArtifact"

        }
    ]
  }
}

The following are the configurable privileges supported for each user role.

The following example shows a configuration file in HOCON format that defines four users: the default admin user name and its assigned AMSAdmin role, and three users and their assigned roles.

// LocalAuthenticationRealm.conf
//
// File the defines users and their roles
LocalAuthenticationRealm = {

  // Users and their passwords and roles. Passwords can be enciphered with the 
     sbcipher utility for additional security.
  
  principals = [
                
    {
       userName = "admin"
       password = "admin"
       roles = ["AMSAdmin"]
    }
      
    {
       userName = "Amy"
       password = "Amy"
       roles = ["Administrator"]
    }

    {
       userName = "Bill"
       password = "Bill"
       roles = ["Business User"]
    }

    {
       userName = "Rob"
       password = "Rob"
       roles = ["Reviewer"]
    }
        
   ]
 }    

The AMS REST API supports queries and returns a set of records, one for each permission string in the query, which indicates whether the logged-in user has the requested permission.

Consult your AMS administrator for the site-specific URL to access the API.