You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For supporting IOTA CAs (see http://wiki.eugridpma.org/Main/IOTASecuredInfraAP) Argus must be able to authorize users based on the combination VO + CA or more specifically, on VO + AP. In short, the IOTA-profile CAs are only allowed for VOs that do sufficient identity vetting, such as the WLCG VOs.
For expressing this efficiently in Argus policies we need to provide new PIPs to set at least the two new attributes
ca-policy-oid
ca-policy-names
Attribute 1. can be obtained from the certificate, and matched in a PAP policy against the OIDs
1.2.840.113612.5.2.2.1 / policy-igtf-classic
1.2.840.113612.5.2.2.3 / policy-igtf-slcs
1.2.840.113612.5.2.2.5 / policy-igtf-mics
1.2.840.113612.5.2.2.6 / policy-igtf-iota
However, since not all CAs provide them reliably, we also need attribute 2 which will indicate in which .info files in the /etc/grid-security/certificates directory the subject DN of the end-entity-certificate issuing CA is found. Furthermore, we need to retrieve the issuer DN of only the end-entity certificate. We cannot obtain that from the unsorted multivalued attribute http://dci-sec.org/xacml/attribute/subject-issuer, but can use the single-valued http://authz-interop.org/xacml/subject/subject-x509-issuer attribute. Hence we suggest using the following attributes:
We suggest implementing two new PIPs, the first of which sets attributes 1 & 2 and the second one using attribute 2 to set attribute 3.
The PAP policy using the information should then for each permit on FQAN or VO also include a match on ca-policy-names. For this reason we suggest adding two new .info files, called
policy-aspen-birch-cedar.info
policy-aspen-birch-cedar-dogwood.info
which will include the 'normal' classic, mics, slcs and iota IGTF policy files. This way, these new policy names can be used in the PAP policies instead of having to reference all 3 or 4 policies separately. E.g. for the WLCG VOs one could reference just policy-aspen-birch-cedar-dogwood
The text was updated successfully, but these errors were encountered:
msalle
added a commit
to msalle/argus-pep-server
that referenced
this issue
Jul 27, 2016
Adding X509ExtractorPIP and PolicyNamesPIP with corresponding
*IniConfigurationParser classes and *Test classes.
PolicyNamesPIP makes use of a sub package policynamespip for a caching the info
files.
This solves argus-authz#15.
Adding X509ExtractorPIP and PolicyNamesPIP with corresponding
*IniConfigurationParser classes and *Test classes.
PolicyNamesPIP makes use of a sub package policynamespip for a caching the info
files.
This solves argus-authz#15.
Hi Andrea,
this has now long been released, both in UMD4 and http://argus-authz.github.io/repo/stable/el7/RPMS/repoview/. Probably good to update the 1_7 branch (i.e. to merge the iota-ca-support branch) and to make the relevent tags...
For supporting IOTA CAs (see http://wiki.eugridpma.org/Main/IOTASecuredInfraAP) Argus must be able to authorize users based on the combination VO + CA or more specifically, on VO + AP. In short, the IOTA-profile CAs are only allowed for VOs that do sufficient identity vetting, such as the WLCG VOs.
For expressing this efficiently in Argus policies we need to provide new PIPs to set at least the two new attributes
Attribute 1. can be obtained from the certificate, and matched in a PAP policy against the OIDs
However, since not all CAs provide them reliably, we also need attribute 2 which will indicate in which .info files in the /etc/grid-security/certificates directory the subject DN of the end-entity-certificate issuing CA is found. Furthermore, we need to retrieve the issuer DN of only the end-entity certificate. We cannot obtain that from the unsorted multivalued attribute http://dci-sec.org/xacml/attribute/subject-issuer, but can use the single-valued http://authz-interop.org/xacml/subject/subject-x509-issuer attribute. Hence we suggest using the following attributes:
see https://www.ogf.org/documents/GFD.205.pdf §6.2.3
see https://www.ogf.org/documents/GFD.205.pdf §6.1.4
a new attribute, string type, multiplicity 0..N
We suggest implementing two new PIPs, the first of which sets attributes 1 & 2 and the second one using attribute 2 to set attribute 3.
The PAP policy using the information should then for each permit on FQAN or VO also include a match on ca-policy-names. For this reason we suggest adding two new .info files, called
which will include the 'normal' classic, mics, slcs and iota IGTF policy files. This way, these new policy names can be used in the PAP policies instead of having to reference all 3 or 4 policies separately. E.g. for the WLCG VOs one could reference just policy-aspen-birch-cedar-dogwood
The text was updated successfully, but these errors were encountered: