What's on this page

Getting Started

The default installation of Stratoss™ Lifecycle Manager (LM) includes a secure application with protected access and a set of preconfigured roles. It also includes predefined users who are able to perform a variety of the key system roles. These predefined users are suitable for either basic usage of the system in a demonstration capacity, or can act as a template for understanding how to configure users in a more permanent installation.


User access in LM is based on 5 principles: Privilege, Roles, Groups, Users and Clients.


A privilege grants permissions to a user to perform an operation in the system. The set of allowed privileges are built into LM, read more information about them at: Available Privileges


A role is a collection of privileges that represent a responsibilty in the system. For example, an “Administrator” role could be created with all possible privileges.

Each role and it’s assigned groups or clients are managed in the configuration for the LM installation.


A group is a collection of users with similar responsibilities. Every role configured on an LM installation is assigned a list of the groups that make use of it (a group may be assigned to more than one role). This results in assigning that role to every user in the group, granting them the priveleges of that role.

LM reads groups from a (potentially external) LDAP server.


A user is a person with access to the system. Their access credentials may be used to make API requests from a valid client and login to the user interface of LM. The actions allowed by a user are dictated by the groups they are a part of.

LM reads users from a (potentially external) LDAP server.


A client is a system allowed to make requests on LM. Each client is assigned a given grant type, which controls the type of authentication requests it may make and potential roles it is assigned.

For example a client may be created with roles, allowing it to authenticate with just it’s own credentials. Alternatively, a client may be assigned the password grant type, so it may only authenticate with it’s credentials in combination with a valid username/password, assuming the roles of the user (the LM user interface is a good example of this, as it allows users to login with their username/password, combines this with it’s own set of credentials to authenticate as the given user)

Even with username/password credentials, the id and secret of a valid client must be included on all authentication requests.