This issue tracks the development of authentication profiles support in Argus.
The topic has been widely discussed among the Argus collaboration, three proposals have been written, which are now collected here. Consensus was reached on proposal 3.
Proposal 3 summary
We propose to define an additional PIP, running in the Argus PEP daemon, that has the responsibility of understanding the LoA of the user certificate in the authorization request and
remove the certificate-related attributes (i.e., subject, subject-issuer, vo, fqan and pfqan and EMI profile equivalents) if the LoA of the user certificate in the authorization request is not allowed by the local authentication profile policy (which will then result in a NotApplicable authorization decision).
We will use the VO-CA-AP policy syntax to define which LoAs are allowed for which VOs and for certificates without VOMS extensions.
This issue tracks the development of authentication profiles support in Argus. The topic has been widely discussed among the Argus collaboration, three proposals have been written, which are now collected here. Consensus was reached on proposal 3.
Proposal 3 summary
We propose to define an additional PIP, running in the Argus PEP daemon, that has the responsibility of understanding the LoA of the user certificate in the authorization request and remove the certificate-related attributes (i.e., subject, subject-issuer, vo, fqan and pfqan and EMI profile equivalents) if the LoA of the user certificate in the authorization request is not allowed by the local authentication profile policy (which will then result in a NotApplicable authorization decision).
We will use the VO-CA-AP policy syntax to define which LoAs are allowed for which VOs and for certificates without VOMS extensions.