Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

ProxyIdP can release information about privileges that the user should be granted in the target application. This information is released in the form of entitlements, which are string values representing individual access rights, user roles, group membership etc.

The values are released differently depending on the authentication protocol used:

  • in SAML, the values are listed in the eduPersonEntitlement attribute

  • in OIDC, the values are listed in the eduperson_entitlement claim in the userinfo endpoint, and scope eduperson_entitlement is required to gain access to this information

ProxyIdP releases several categories of entitlement values.

Forwarded entitlements

If the user has multiple linked identities, and the home Identity Provider sent some entitlements about the user, ProxyIdP will forward these entitlements as they are to the service.

The specific format of these entitlements depends on their issuer.

Group entitlements

ProxyIdP releases entitlements also based on group membership and groups assigned to the service in Perun IDM. For convenience, ProxyIdP will release an entitlement value for each group which the user is a member of, if that group is assigned to a resource on the facility which represents this service.

The generation of these entitlements follows https://doi.org/10.5281/zenodo.6533400 . The format of each value is:

<NAMESPACE>:group:<GROUP>[:<SUBGROUP>*][#<AUTHORITY>]

where

  • <NAMESPACE> is a prefix which represents the instance of ProxyIdP

  • <GROUP> is the short name of the virtual organization of the group

  • [:<SUBGROUP>*] contains the full group name, if the user is a member of a group (URL encoded)

  • [#<AUTHORITY>] is a suffix which represents the instance of Perun IDM

Examples:

  • urn:geant:muni.cz:group:MU#idm.ics.muni.cz - member of a VO called MU

  • urn:geant:cesnet.cz:group:einfra:group1#perun.cesnet.cz - member of a group called group1 in a VO called einfra

How to configure group entitlements

The downside of this approach is that the value of the entitlement changes when the group is renamed or moved. This poses a risk of breaking access when using multipurpose groups. For a more stable solution, see resource capabilities below.

Group entitlements are configured in the Perun IDM. Groups need to be assigned to a resource on the corresponding facility, and ProxyIdP will start to release group entitlements automatically.

Resource capabilities

To prevent access control from breaking when groups are renamed or remove, we highly recommend using entitlements in the form of resource capabilities. This form of entitlement effectively represents a M:N mapping of groups to entitlement values; multiple groups may be mapped to the same capability, and also one group may grant users multiple capabilities.

The generation of these entitlements follows https://doi.org/10.5281/zenodo.2247446 . The format of each value is:

<NAMESPACE>:res:<RESOURCE>[:<CHILD-RESOURCE>]...[:act:<ACTION>[,<ACTION>]...]#<AUTHORITY>

where

  • <NAMESPACE> is a prefix which represents the instance of ProxyIdP

  • res:<RESOURCE>[:<CHILD-RESOURCE>]...[:act:<ACTION>[,<ACTION>]...] is the resource capability value set in Perun IDM

  • [#<AUTHORITY>] is a suffix which represents the instance of Perun IDM

Examples:

  • urn:geant:cesnet.cz:res:TestingCapabilitiesValue1#perun.cesnet.cz - generated from res:TestingCapabilitiesValue1

  • urn:geant:cesnet.cz:res:books:act:read#perun.cesnet.cz - generated from res:books:act:read

How to configure resource capabilities

Resource capabilities are configured in the Perun IDM. Groups need to be assigned to a resource on the corresponding facility, and resource attribute Resource capabilities needs to be set to a value in the format res:<RESOURCE>[:<CHILD-RESOURCE>]...[:act:<ACTION>[,<ACTION>]...]

The specific value can be chosen depending on the service’s requirements. Each capability may represent:

  • user’s workplace (e.g. res:workplace:12345)

  • a part of the system which the user is allowed access to (e.g. res:agenda1:act:read)

  • a role which the user should be granted (e.g. res:admin)

Resource capabilities may be “nested” - for example by combining capabilities res:user, res:user:read and res:user:write, the access control inside the application may be greatly simplified.

Each resource may grant multiple capabilities, multiple resource may grant the same resource capability.

For convenience, if all resources should grant the same capability, instead of adding it to all individual resources, you may set facility attribute Facility capabilities to this value. Users in all groups on all resources will be granted this capability.

  • No labels