How the authorization information is used in matchmaking

The following expression is evaluated at matchmaking time in order to check whether the owner of a job has access rights to a given CE.

AuthorizationCheck = ( member(other.CertificateSubject, GlueCEAccessControlBaseRule) || member(strcat("VO:",other.VirtualOrganisation), GlueCEAccessControlBaseRule) || FQANmember(strcat("VOMS:",other.VOMS_FQAN), GlueCEAccessControlBaseRule) ) && ! FQANmember(strcat("DENY:",other.VOMS_FQAN), GlueCEAccessControlBaseRule);

We check if either the certificate subject or the virtual organization the user belongs to is member of the GlueCEAccessControlBaseRule (ACBR henceforth in text) of the CE.

The third expression in logical OR condition has been added in order to support generic attributes specification in the ACBR and tests for ownership of the primary FQAN specified in the user-proxy. The VOMS_FQAN attribute in the JDL is assigned with such a value.

The classad built-in member function, while testing for ownership in the ACBR list, uses a lexical match (classic string compare). The FQANmember function as the list mernership built-in fuction member(V,L) takes two arguments: the FQAN and the list of ACBR. The FQANmember returns true if and only if the FQAN is a member of the ACBR list and uses an ad-hoc comparator while testing for ownership.

The MM receives the authorization information i.e. ACBR from the classad representation of a CE, which is generated starting from the information the BDII publishes for that CE.

-- FrancescoGiacomini - 09 Oct 2007

This topic: EgeeJra1It > WebHome > AuthZinMM
Topic revision: r2 - 2007-10-09 - SalvatoreMonforte
This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback