Unable to login with CERN secondary account

[vokac]

CERN secondary account doesn't provide cern_person_id and SSO

[federicaagostini]

Hi Petr, this is due to deployment restrictions. The related configuration of the Atlas IAM is

oidc:
  providers:
    - validator:
        kind: hasClaim
        params:
          claimName: cern_person_id

This forces users to login with CERN credentials rather than CERN SSO linked accounts. I guess this choice was done because one can retrieve the CERN username from the SCIM API afterwards.

Can you please confirm that in the WLCG IAM you can connect a secondary account?

[vokac]

I can confirm that secondary CERN account works with WLCG IAM. May be cern_person_id claim from SSO token is used during ATLAS registration to fill account label with prefix hr.cern and name cern_person_id which is later used for suspension according HR database.

[federicaagostini]

Yes, I confirm that it is also used for that reason.

May I close the issue, then?

[vokac]

We decided to use CERN secondary accounts for privileged users => SSO should work also for these accounts that doesn't provide cern_person_id in the token. We should discuss how to proceed during WLCG AuthZ meeting, because on the other hand it is not clear to me why cern_person_id is not included in tokens for secondary account.

[federicaagostini]

Ok, let's discuss it later.

Anyhow, if there is some other CERN-related claim which is present in the ID tokens issued by the CERN SSO after login with both primary and secondary account, one could change the configuration such to validate the token based on that claim. Then the problem would be that IAM wouldn't be able to check the user's membership in the CERN HR DB ending up with deleting the user (unless the hr.cern = ignore label is set).

I have tried to check for the list of claims supported by the CERN SSO (here) but I don't even see the cern_person_id.

[maarten-litmaath]

Hi all, might we add an extra authentication method just for secondary accounts?

Almost identical to what we have for SSO, but without the cern_person_id requirement?

[chaen]

Actually, how are we supposed to proceed for people with primary account in one experiment and secondary account in another one ? Or even robot certificates. During the initial voms-import step, it's fine, the account is created, the certificate imported, and then the user can login with the certificate instead of SSO. But for an initial registration ? What is the workaround for now ?

[vokac]

Considering small number of these cases (< 3%) we decided that these can be created manually by experts. VO administrators can create new user account using IAM web interface, the only problem is linking account to CERN ID and (primary) SSO, but this can be done with API, e.g.

$ export BEARER_TOKEN=$(oidc-token VO-ADMIN)
$ export ACCOUNT_UUID=00000000-0000-0000-0000-000000000000
$ curl -v -X PUT -d '{ "prefix": "hr.cern", "name": "cern_personal_id", "value": "000000" }' -H 'Content-type: application/scim+json' -H "Authorization: Bearer ${BEARER_TOKEN}" https://atlas-auth.cern.ch/iam/account/${ACCOUNT_UUID}/labels
$ curl -X PATCH -H 'Content-type: application/scim+json' -H "Authorization: Bearer ${BEARER_TOKEN}" -d '{ "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ], "operations": [ { "op": "add", "path": "oidcIds", "value": { "urn:indigo-dc:scim:schemas:IndigoUser": { "oidcIds": [ { "issuer": "https://auth.cern.ch/auth/realms/cern", "subject": "girolamo" } ] } } } ] }' https://atlas-auth.cern.ch/scim/Users/${ACCOUNT_UUID}

Secondary account can't be also used to login even with existing IAM account ... this is a bit unexpected behavior.

[federicaagostini]

Hi Petr, which error do you get when logging in with a manually linked secondary account? If it is something like "Claim 'cern_person_id' not found", the point is that the claim validation, based on the presence of cern_person_id in the ID token, happens at any login with external provider (CERN). So, even if you add a label with some cern_person_id, the login will not work.

[vokac]

As discussed during today's WLCG AuthZ meeting, cern_person_id from CERN SSO token should be used only during registration and ignored while logging to the IAM account linked to the secondary CERN account (that doesn't provide cern_person_id in the token).

[msalle]

Just to make sure I understand correctly: the IAM account will get disabled when the user is no longer in the CERN HR DB right? (this to prevent the user from being able to still login after the main account gets disabled, common problem with account linking).

[federicaagostini]

Hi all, looking more deeply into IAM configuration parameters and CERN configurations we ended up with the following considerations (writing here as reference):

• in order to enable the validation at any login with external OIDC provider, based on the cern_person_id claim, one has to set the following properties

  oidc:
  providers:
    - validator:
        kind: hasClaim
        params:
          claimName: cern_person_id
      ...

• in order to enable the validation at registration time based on the cern_person_id claim AND to validate the user based on the cern_person_id label during the HR DB lifecycle, one has to set the following property in a dedicated application-cern.yml file:

  cern:
  person-id-claim: cern_person_id

In conclusion, to solve the issue of the impossibility to add CERN secondary accounts, we can remove the first validation from configuration (but the accounts still need to be created manually, in order to bypass the second validation).

[maarten-litmaath]

Ciao IAM devs, will this at least still require ordinary users to have their primary account in good shape and linked to their IAM account?

We would not want to open the door for mistakes or abuse, just to make a minor use case easier to handle...

[vokac]

Described configuration would be fine for us: we can just add in our VO documentation that people who want to use secondary account must contact VO Admins (we are talking about 3% of our users ... we don't have to make it easy for secondary accounts)

And to prevent users with secondary account to accidentally create second IAM account with their primary CERN identity we'll always keep also primary CERN SSO linked to these accounts.