Permissions#
The eleven permissions the package declares, and who holds them after a default install.
Permission id |
Title |
Roles site-wide |
|---|---|---|
|
Add User Profile |
nobody |
|
Add User Group |
nobody |
|
Add Principals Container |
Manager, Site Administrator |
|
Edit Profile |
Manager, Site Administrator |
|
Edit Profile Group Membership |
Manager, Site Administrator |
|
Edit Profile Login |
Manager |
|
Edit Group Global Roles |
Manager |
|
View Profile |
Manager, Site Administrator |
|
View Personal Identifiable Information |
Manager, Site Administrator |
|
View Account Details |
Manager, Site Administrator |
|
Export Identity Providers |
Manager |
Every one is declared with acquire="False".
Why the two add permissions are granted to nobody#
That is deliberate, not an oversight.
Both content types are addable in exactly one place: the container the registry
names for them, where the package grants the permission to Manager and Site
Administrator locally. Granting it site-wide as well would make every folder
in the site a place a UserProfile can be created, which is the thing being
prevented.
principalscontainer.add is granted site-wide, and that leaves the lock
intact. A Principals folder created anywhere but the configured path
receives neither of the two add permissions.
Why acquire="False" matters even with no roles listed#
A permission nobody mentions is not a permission nobody has. Zope falls back to whatever the object acquires, so the answer would change with where the folder happens to be. Stating the permission with no roles pins it.
The field permissions#
content.edit, content.editgroups, content.editlogin, content.view,
content.viewaccount and content.viewpii are field permissions declared on the Profile schema and on
its behaviors. Each is also managed by user_profile_workflow, which decides
who may read and write a Profile in each of its states.
The rolemap entries above are the site-wide floor for anywhere the workflow does not reach.
Group membership is its own permission#
content.editgroups is separate from content.edit and is never granted to
the profile's owner, in any state.
group_ids decides which groups a user is in, so writing it is granting yourself
roles.
A group's roles are stricter still#
content.editroles guards global_roles on a group, and is granted to
Manager alone—not to Site Administrator, unlike the membership permission
above it.
group_ids decides who is in a group; global_roles decides what the group
is allowed to do, which is one step further along the same path. Anyone able
to write it could grant the group Manager and then add themselves to the
group, so under the ordinary edit permission "tidy up a group" and "become an
administrator" would be the same action.
Delegating group membership to a Site Administrator is a normal arrangement. Delegating the power to mint administrators is not.
A login is its own permission, and it depends where you ask#
content.editlogin is separate from content.edit, and it is the one
permission in this table whose answer differs between a Profile and the folder
Profiles are filed in.
Asked about |
Who holds it |
Which form asks |
|---|---|---|
A |
Manager |
the edit form |
The container |
Manager, Site Administrator |
the add form |
That is what "a Manager may change a login after the account exists" is made
of. plone.autoform checks a field's write permission against the form's
context, which is the container on an add form and the object on an edit form,
so the two grants answer two different questions.
login is half of the case-folded index user enumeration queries. Rewriting it
moves an account away from every sign-in, every Sharing entry written against
the old name, and every provider that maps a user by it.
The machine paths that mint an account are unaffected: doAddUser elevates to
Manager and writes the field through the Dexterity factory, which does not
consult a field permission at all.
Personal information is its own permission#
content.viewpii is separate from content.view so a site can let members find
each other without publishing everybody's email address.
Account details are their own permission#
content.viewaccount, titled View Account Details, guards login and
group_ids on a Profile. content.view guards the public fields. A site that
opens those to Anonymous would otherwise open the login that signs the account
in, and the groups that decide which roles it holds, along with them.
user_profile_workflow maps it in every state, with the roles View Profile
holds in that state. A site that does not change its workflow sees no change.
One consequence is stated here rather than left implicit: Member reads the
login and the groups of a complete Profile by default, as it reads the name.
To take that away, remove Member from the View Account Details map in the
complete state.
A group's group_ids carries the same permission, because a group and a user
share the membership behavior. The group workflow does not map View Profile,
so the permission falls to the site rolemap, which names Manager and Site
Administrator, as View Profile did.
The workflow never grants it to Member, in any state.
Exporting providers is its own permission#
providers.export guards @identity-providers/@export,
@identity-providers/<id>/export, and the control panel's export actions that
download what they return. It is granted to Manager alone.
An export is a backup of the provider records, and a backup that left the client secrets out would restore providers unable to authenticate, so every export carries them in the clear. Managing a provider never needs its secret back: the control panel and the rest of the API send only the mask.
Manage portal, which guards the rest of the provider control panel, is also
Manager's alone on a default site. The export permission is separate so that a
site giving another role Manage portal, to let it manage the providers, does
not give that role every client secret along with it.
Permissions this package uses but does not declare#
Permission |
Used by |
|---|---|
|
the provider and client control panels, except the provider exports; the audit log, driver listing, key rotation |
|
|
See Endpoints for which endpoint enforces which.