Last modified 11 years ago Last modified on 12/14/09 16:14:57

[part of a series of meetings]

Proper handling of a user's FQAN


Brief introduction

A user declares that they are a member of one or more VOs by "attaching" one or more FQANs to their proxy certificate. These FQANs are provided (and signed) by a VOMS server.

A FQAN has the form /<VO>[/<group>[/<subgroup>]][/Role=<role>][/Capability=<cap>]. A user that is a member of group <group> of VO <VO> (an FQAN of /<VO>/<group>) is always a member of the VO <VO> (FQAN /<VO>). The VOMS server will provide a complete list of all FQANs the user is a member of. The format is described here.

A request from a user may attract multiple PDPs (Policy Decision Points). Examples of these PDPs are SRM space allocation, pool selection, name-space permissions, staging, etc. The user making the request may have multiple FQANs. How should the aggregate decision ("allow this user's requested operation") be built from the different PDPs?

Adding wild-card support in LGAF?

Should we add support for wildcards in the LinkGroupAuthorizationFile? What are the use-cases that would need it? Are these use-cases satisfied by existing code and VOMS behaviour?

Suggested Reading:

Multiple FQANs for SrmSpaceManager

Current behaviour is for doors to cycle through all FQANs that the user supplied: the one that wins is used for the request. This is ugly.

What are the correct behaviour for the space manager when the user has presented multiple roles?

How to we go about fixing the current door / space-manager interaction?

How to record authorisation decision