Skip to content

Missing check that top-level group is the VO name #42

@paulmillar

Description

@paulmillar

From GFD 182 (page 6) §3.4.1.2:

Groups are organized in a tree structure, meaning that a group may have subgroups, which in
turn may have subgroups, etc… The group name is then represented in the following way:

/<root group>/<subgroup>/…/<subgroup>

Where <root group> MUST be the name of the virtual organization.

Therefore, I believe the voms-api-java library should check whether this condition is held, when validating the AC.

From a quick inspection (checking v3.3.3), it seems that the o.i.v.a.i.DefaultVOMSValidationStrategy class makes no check on the VO name, which would allow the inconsistency where the AC's VO name does not match a FQAN's <root group>.

Please consider updating DefaultVOMSValidationStrategy by adding a test for this situation.

I have no strong opinion on how to handle situations where an FQAN's <root group> is not the VO name. One option would be to reject the complete AC, another option is to accept the AC but filter out any inconsistent FQANs. I would tend towards the latter, but (as mentioned), this isn't a strong opinion.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions