select_raa causes user with an RAA role to incorrectly have RAA rights in other institutions

[phavekes]

This issue is imported from pivotal - Originaly created at Dec 31, 2019 by Pieter van der Meulen

Given: a user that only has the "raa @ institution-g.nl" role

This user has RAA rights to add and remove roles for users in institution-h.

Config: "institution-g.nl": { "use_ra_locations": true, "show_raa_contact_information": true, "verify_email": false, "allowed_second_factors": [ ], "number_of_tokens_per_identity": 2, "use_ra": [ "institution-g.nl" ], "use_raa": [ "institution-g.nl" ], "select_raa": [ "institution-g.nl", "institution-h.nl" ] }, "institution-h.nl": { "use_ra_locations": true, "show_raa_contact_information": true, "verify_email": false, "allowed_second_factors": [ ], "number_of_tokens_per_identity": 2, "use_ra": [ "institution-h.nl" ], "use_raa": [ "institution-h.nl" ], "select_raa": [ "institution-h.nl", "institution-g.nl" ] },

Because institution-g.nl is not included in the use_raa list for institution-h.nl, users with the raa @ institution-g.nl role must not get RAA rights in institution-h.nl. The bug is that they do get some.

Vetting users for institution-h.nl and viewing the institution configuration for institution-h.nl is not possible, which is correct.

Tested with Middleware 3.0.2, RA 3.0.1

Todo Try to reproduce and get a feel for the impact Estimation: 1-4h (to get a grip on the problem and be able to estimate time for a fix)

[phavekes]

Currently it seems to work as I would expect and I\'m not able to reproduce the bug so I\'ll need some additional information to dive deeper into the rabbit hole.

@pmeulen could you supply the results from the query below (the common_name must be changed to the common name of the RAA user in the use-case above)? SELECT * FROM ra_listing WHERE common_name=\'USER?\';

@pmeulen Would you be so kind to explain how I\'ll be able to reproduce the bug :The bug is that they do get some.

May I also ask what you are trying to achieve with this configuration? So I\'ll be able to do some additional testing when I complete the story.

Thanks in advance! (bstrooband - Jan 7, 2020)

[phavekes]

@bstrooband 

Query SELECT * FROM ra_listing WHERE common_name=\'pieter-g-raa institution-g.nl\'; gives 1 result:

# id, identity_id, institution, common_name, email, role, location, contact_information, ra_institution
\'15\', \'53c89809-3a6a-4e65-b0f2-e192a2764d25\', \'institution-g.nl\', \'pieter-g-raa institution-g.nl\', \'pieter+pieter-g-raa@surfnet.nl\', \'raa\', \'x\', \'x\', \'institution-g.nl\'

With The bug is that they do get some. I mean that the user does get SOME of the rights that an RAA would have (namely the possibility to manage RA and RAA roles for institution-h.nl, which is an institution where they COULD have an RAA role, but where they don\'t have one). Other actions that an RAA could perform like the ability to vet users or view the configuration for the institution where not present. Note that I didn\'t try all possible actions. Also noto that both the RA and the middleware were wrong about this. I could actually assign (and then remove) the role.

(Pieter van der Meulen - Jan 8, 2020)

[phavekes]

The problem was that if a user was made RA(A) for an institution defined in the SELECT_RAA configuration the USE_RA(A) institutions of that institution weren\'t taken into account anymore. This is fixed. I directly added some inline documentation, added extra inline documentation and removed duplicate logic to simplify things more if I could. (bstrooband - Jan 15, 2020)