04-permissions.md

---
title: "About Permissions"
teaching: 10
exercises: 10
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
---

# 3. About Permissions

Several actions within COmanage require specific permissions to perform them. Permissions are usually granted by making a `CO Person`:gear: a part of a group, and then granting permission to that group to do specific tasks. 

The types of actions that can require special permission include:

* Configuring the COmanage platform or specific organizations or collaborations represented in the platform
* Enrolling (registering) people in COmanage
* Managing `CO Person`:gear: objects, their connected attributes (information), and the values stored for the person. 
* Managing one's own attributes (information) (Self Service Permissions)
* Creating and managing groups and who is included in the groups

# Automatic permission groups

Some groups for managing these permissions are created automatically when configuring the objects that you will use when modeling your organization. (Next lesson!)

* **Admin groups** - for some component that you use to model your organization, a group will be created for each that will contain administrators for that organizational component. Members of this group will have permissions allowing them to manage the organizational component and the things attached to the organizational component. There is also a general **admins** group that contains all people who are an admin in any capacity.
* **Active Members group** - All people registered with an active status in COmanage will be included in this group. Members of this group will have permissions allowing them to do thing like signing into COmanage.

# Guest permissions

COmanage allows you to configure it to let people who are not fully registered (guests) to see some information stored on the platform (for example, a person directory or list of groups.) (_What specifically is being referred to here? Guests is an ambiguous term - Registry itself has no such defined concept. Users either have permission to do something or they don't._) The platform also enables you to allow guests to create their own accounts (self enroll), for example, to join a group for a mailing list or to access specific resources. We will talk more about these capabilities in a later lesson about enrollment workflows.

# Self Service Permissions

COmanage allows certain attributes (information) to be managed by users directly.

## Attributes always available for self service

* `CO Person`:gear: NSF Demographic attributes (an optional COmanage component) (_maybe omit this? nobody really uses it and we'll probably deprecate it_)
* `CO Person`:gear: Preferred Timezone (_This is really a technical thing and not so much a user preference - timezone is typically determined automatically_)
* `CO Group`:gear: Memberships (for open groups or groups owned by the CO Person) - _we will be talking about Groups in the next lesson._
* SSH Keys attached to a CO Person record - _we will be talking about authenticators and SSH Keys in a later lesson._

## Attributes that may be configured for self service

* `CO Person`:gear: Name
* `CO Person`:gear: Role Address
* `CO Person`:gear: EmailAddress
* `CO Person Role`:gear: TelephoneNumber
* `CO Person`:gear: Identifier
* `CO Person`:gear: URL (as of v3.1.0) (_it's probably safe to omit version numbers and just assume everybody is using the latest version, or whatever version you're training with_)

_By default, these attributes are read only._

## Attributes that are never available for self service

* `CO Person`:gear: Status
* `CO Person Role`:gear: attributes
* All attributes attached to an `Org Identity`:gear: record

---

# Hands on - Starting our person model

![Interactive system activity](/assets/img/hands-on-keyboard.png)

Consider the people that you have been using as examples in your [ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf) worksheet. What permissions would each of these individuals have? 

* Consider the items that you listed in the Memberships section. Would this person be an Owner or Administrator for any of these collections of people? 
* Would this person be considered a platform administrator, responsible for setting up organizational structure within COmanage?
* Would this person be allowed to change attributes (information) about themselves, for example, email address, name or phone number?
* Would this person be allowed to self enroll for any memberships? If so, what types of groups would this person elect to be a part of?
* Is this person considered a guest - i.e., the person has a limited connection to your organization or collaboration.

Jot down your thoughts on the worksheet. There are check boxes to indicate things like administrative or ownership permissions as well as self service or self enrollment privileges. 

[10 min]

---
< TO BE UPDATED >

# Terminology

## COmanage Objects :gear:

OBJECT | DESCRIPTION
------ | -----------
`CO Person`:gear: | the representation of a person in COmanage
`CO Person Role`:gear: | the representation of a person's role in COmanage. This object describe the person's role with certain collections of people within your organization or collaboration. These objects are attached to :gear: `CO Person` objects; there may be any number of Roles.

## Worksheets

WORKSHEET | DESCRIPTION
--------- | -----------
[ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage

## Slides

To be included

---

NEXT SECTION: [5. Your first person!](/_episodes/05-firstPerson.md)

PREVIOUS SECTION: [3. About Authenticators](/_episodes/03-authenticators.md)

LESSON OVERVIEW: [CO310 - Modeling People in COmanage](../index.md)

WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md)