user-types.html.md.erb

---
title: Understanding Pivotal Cloud Foundry User Types
owners: CAPI, Identity
---

<strong><%= modified_date %></strong>

This topic describes the types of users in a Pivotal Cloud Foundry (<%= vars.product_name %>)  deployment, their roles and permissions, and who creates and manages their user accounts. 

The users who run a <%= vars.product_name %> deployment and have admin privileges are [operators](#operator). With Elastic Runtime installed to host apps, you add two more user types: [Elastic Runtime users](#er-user) who develop the apps and manage the development environment, and [end users](#end-user) who just run the apps.

<%= vars.product_name %> distinguishes between these three user types and multiple user roles that exist within a single user type. Roles are assigned categories that more specifically define functions that a user can perform. A user may serve in more than one role at the same time.

## <a id="operator"></a>Operators


Operators have the highest, admin-level permissions. We also refer to operators as Ops Manager admins and Elastic Runtime admins because they perform an admin role within these contexts.

### <a id="operator-tools-tasks"></a>Tools and Tasks

 Operators fulfill system administrator roles covering the entire <%= vars.product_name %> deployment. They work primarily with their IaaS and Ops Manager, to configure and maintain Elastic Runtime component VMs. The component VMs, in turn, support the VMs that host applications. Typical operator tasks include:

* Deploying and configuring Ops Manager, Elastic Runtime, and other product and service tiles.
* Maintaining and upgrading <%= vars.product_name %> deployments.
* Creating user accounts for Elastic Runtime users and the orgs that Elastic Runtime users work within.
* Creating service plans that define the access granted to end users.

### <a id="operator-accounts"></a>User Accounts

When Ops Manager boots for the first time, the operator specifies one of the following authentication systems for operator user accounts:

1. Internal authentication, using a new UAA database that Ops Manager creates.
1. External authentication, through an existing identity provider accessed via SAML or LDAP protocol.

The operator can then use the UAAC to [create more](../customizing/opsman-users.html) operator accounts.


## <a id="er-user"></a>Elastic Runtime Users

Elastic Runtime users are app developers, managers, and auditors who work within orgs and spaces, the virtual compartments within a deployment where Elastic Runtime users can run apps and locally manage their roles and permissions.

A Role-Based Access Control (RBAC) system defines and maintains the different Elastic Runtime user roles:

* Org Manager, Org Auditor, Org Billing Manager
* Space Manager, Space Developer, Space Auditor

The [Orgs, Roles, Spaces, Permissions](../concepts/roles.html) topic describes the Elastic Runtime user roles, and what actions they can take within the orgs and spaces they belong to. Some of these permissions depend on the values of [environment variables](../customizing/console-env-variables.html).

### <a id="er-user-tools-tasks"></a>Tools

Space Developer users work with their software development tools and the apps deployed on host VMs.

All Elastic Runtime users use system tools such as the cf CLI, PCF Metrics, and [Apps Manager](../console/index.html), a dashboard for managing Elastic Runtime users, orgs, spaces, and apps.

### <a id="er-user-accounts"></a>User Accounts

When an operator configures Elastic Runtime for the first time, they specify one of the following authentication systems for Elastic Runtime user accounts:

1. Internal authentication, using a new UAA database created for Elastic Runtime. This system-wide UAA differs from the Ops Manager internal UAA, which only stores Ops Manager Admin accounts.
1. External authentication, through an existing identity provider accessed via SAML or LDAP protocol.

In either case, Elastic Runtime user role settings are saved internally in the Cloud Controller Database, separate from the internal or external user store.

Org and Space Managers then use Apps Manager to invite and manage additional Elastic Runtime users within their orgs and spaces. Elastic Runtime users with proper permissions can also use the cf CLI to assign user roles.

Operators can log into Apps Manager by using the **UAA Administrator User** credentials under the **Credentials** tab of the Elastic Runtime tile. These UAA Admin credentials grant them the role of Org Manager within all orgs in the deployment. The UAA Admin can also use the UAAC to create new user accounts and the cf CLI to assign user roles.


##<a id="end-user"></a>End Users

End users are the people who log into and use the apps hosted on Elastic Runtime. They do not interact directly with Elastic Runtime components or interfaces. Any interactions or roles they perform within the apps are defined by the apps themselves, not <%=vars.product_full %>.

### <a id="end-user-accounts"></a>User Accounts and SSO

App developers can configure apps any way they want to grant end user access individually. In a deployment with [Single Sign-On Service for Pivotal Cloud Foundry&reg;](http://docs.pivotal.io/p-identity/index.html) installed, they can also offer end users a single login that accesses multiple apps.

The Single Sign-On (SSO) service can save user account information in an external database accessed via SAML or LDAP, or in the internal Elastic Runtime user store, along with Elastic Runtime User accounts.

To make the SSO service available to developers, an operator creates service plans that give login access to specific groups of end users. A Space Manager then creates a local instance of the service plan, and registers apps with it. Apps registered to the plan instance then become available via SSO to all end users covered by the plan.

## <a id='table'></a>User Types Summary

The following table summarizes PCF user types, their roles, the tools they use, the System of Record (SOR) that stores their accounts, and what accounts they can provision.

<table id='users-summary' border='1' class='nice'>
	<col width="20%">
	<col width="20%">
	<col width="20%">
	<col width="20%">
	<col width="20%">
	<tr>
		<th>User Type</th>
		<th>Available Roles</th>
		<th>Tools They Use</th>
		<th>Account SOR</th>
		<th>Accounts They Can Provision</th>
	</tr><tr>
		<th>Operators</th>
		<td>Admin (UAA Admin, SSO Plan Admin, other system admins)</td>
		<td>
			<ul>
				<li>
					IaaS UI
				</li>
				<li>
					PivNet
				</li>
				<li>
					Ops Manager
				</li>
				<li>
					cf CLI
				</li>
				<li>
					UAA CLI (UAAC)
				</li>
				<li>
					SSO Dashboard
				</li>
				<li>
					Marketplace
				</li>
			</ul>
		</td>
		<td>
			Ops Manager user store via UAA<br>
			&nbsp;&nbsp;<i>or</i><br>
			External store via SAML or LDAP</td>
		<td>Operators and Elastic Runtime Users</td>
	</tr><tr>
		<th>Elastic Runtime Users</th>
		<td>
			<ul>
				<li>
					UAA Administrator
				</li>
				<li>
					Org Manager
				</li>
				<li>
					Org Auditor
				</li>
				<li>
					Org Billing Manager
				</li>
				<li>
					Space Manager
				</li>
				<li>
					Space Developer
				</li>
				<li>
					Space Auditor
				</li>
			</ul>
		</td>

		<td>
		 	<ul>
				<li>
					cf CLI
				</li>
				<li>
					CAPI
				</li>
				<li>
					Apps Manager
				</li>
				<li>
					PCF Metrics
				</li>
				<li>
					Marketplace
				</li>
			</ul>
		</td>
		<td>Elastic Runtime user store via UAA<br>
			&nbsp;&nbsp;<i>or</i><br>
			External store via SAML or LDAP</td>
		<td>Elastic Runtime Users within permitted orgs and spaces, and <br>
		End Users</td>
	</tr><tr>
		<th>End Users</th>
		<td>Defined by apps they use</td>
		<td>Hosted apps</td>
		<td>Individual apps<br>
			&nbsp;&nbsp;<i>or</i><br>
			Elastic Runtime user store via SSO</td>
		<td>N/A</td>
	</tr>
</table>