request-id-1 alice roles=dictator 07 Nov 19 19:38 UTC PENDING
$ tsh login --request-id=request-12345
Granted by Bob... logging in
```
## User interface flows
Imagine Bob has the following default role:
```yaml
kind: role
metadata:
name: contractor
spec:
allow:
request:
roles: ['^customer-.*$']
```
Users will have several options:
**Option 0: Requesting access during the login in the UI or the CLI**
Teleport login screen will have a separate optional field: "Request access". Alice
clicks "Request access" expandable section and adds a note with a ticket number.
Once Alice enters a reason, Teleport will create an `access_request` with note
provided by her in case if login is successful. The user interface shows
a screen "Requesting access, please wait" as a separate state after the login
and redirects back to the UI or tsh.
**Option 1: Requesting access after login in the UI**
Once in the system, Bob clicks on the top right nav corner and
fills in fields request access dialog window:
* Selects a role from the list
* Optionally adds a reason - `ticket-1234`
He then waits for the request to be granted or denied. The user interface shows
a screen "Requesting access, please wait" as a separate message in the user interface.
**Option 2: Requesting access through the node list in the UI**
Alice goes to the nodes list, selects a node and clicks on the drop down action
'request access':
* Selects or enters new SSH principal
* Optionally adds a note - ticket-1234
She then waits for the request to be granted or denied.
**Approved**
In both cases, Bob waits until the request gets approved, and in the case
if it does, Bob sees a notification, UI gets reloaded and Bob gets access
to the node/or sees the new list of nodes.
## Examples
#### Automatic approval for contractors
Let's go back the the example of 'Acme Co' and craft a plugin design that will
approve the request to cluster whenever there is a ticket assigned to a user.
**Roles**
On the root cluster `acme`, let's define the default role all contractors are
assigned to by default:
```yaml
kind: role
metadata:
name: contractor
spec:
allow:
request:
roles: ['^customer-.*$']
```
This role assigned to all contractors by default lets users to request access to customer related roles.
Second role `customer-a` lets clients to see leaf cluster `customer-a` and access it:
```yaml
kind: role
metadata:
name: customer-a
spec:
options:
# limit max session TTL to 1 hour and disconnect the connection
# when the certificate expires
max_session_ttl: 1h
disconnect_expired_cert: yes
allow:
cluster_labels:
customer: 'customer-a'
```
Contractors are not assigned to this role, but can request access to it.
Leaf clusters are autonomous and have their own set of roles. Leaf cluster `a`
will define local role:
```yaml
kind: role
metadata:
name: remote-contractor
spec:
options:
# limit access to a separate SSH principal
logins: [contractor]
allow:
node_labels:
# limit access to some nodes
'access': 'contractor'
```
Trusted cluster spec will map `customer-a` role to `remote-contractor` role:
```yaml
kind: trusted_cluster
metadata:
name: "acme"
spec:
enabled: true
role_map:
- remote: customer-a
local: [remote-contractor]
```
**User experience**
Contractors will log in and enter the note / ticket number. Teleport will generate
access request and if granted by plugin based on the ticket number or meta data in
the request, they will see the clusters to access.
## Audit Log
All request events will be tracked by Teleports Audit Log. These will recorded under
access_request. These are tracked using these two event codes.
`T5000I` - AccessRequestCreateCode is the the access request creation code.
`T5001I` - AccessRequestUpdateCode is the access request state update code.
AccessRequestUpdateCode provides an option for plugins to update the state off a request
with extra meta data about its reason for who approved, or why it was denied. See (Teleport Plugin)[https://github.com/gravitational/teleport-plugins/blob/22334ec352bc62fc6bddd98f2284228442da73fb/access/access.go#L128] as an example.
