Institution specific LoA determination for unknown user

[phavekes]

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

Looking at https://github.com/OpenConext/Stepup-Gateway/blob/develop/src/Surfnet/StepupGateway/GatewayBundle/Service/StepUpAuthenticationService.php#L189 it appears that the institution that the user being authenticated belongs to is determined by logging up the user by NameID in the second_factor table in the gateway. This lookup is only possible for users that the gateway knows about, i.e. users that have a vetted second factor. For other users this fails (i.e. no results).

A typical loa configuration would be:

"loa": {
  "__default__": "http://example.org/loa1",
  "institution-a.example.org": "http://example.org/loa2",
  "institution-b.example.org": "http://example.org/loa2"
},

The expected behaviour is that all users of instatution-a and instatution-b are required to authenticate at loa2 (i.e. require stepup), not just the users of these institutions that have a vetted token. Users not belonging to these institutions require loa1 (i.e. no stepup required).

Related to:

• 149563137

See:

• Stepup-Deploy docs

[phavekes]

@pmeulen, to validate we\'re on the same page: instead of getting the institution of the authenticating user from the second_factors table (current situation `StepUpAuthenticationService.php#L189`). 

The institution should be based on the schacHomeOrganisation attribute value of the authenticating user. (Michiel Kodde - Dec 12, 2017)

[phavekes]

Yes, that is what is expected. The schacHomeOrganisation attribute is what identified which organisation the user belonged to during the registration process in the selfservice interface. There are some details we need to work out:

1. The schacHomeOrganisation attribute may not be present. How to handle this case?
2. What if the schacHomeOrganisation during an authentication is different from the schacHomeOrganisation that was presented during registration? (Pieter van der Meulen - Dec 12, 2017)

[phavekes]

I\'ve updated the list of actions based on your questions. My proposal is the following (and please verify if this makes sense :) )

1. In the GatewayController::consumeAssertionAction when saving the assertion, the SHO is to be saved to the state handler. The SHO is retrieved from the assertion by its Urn mace identifier. Should I add fallback to also support the Urn oid for the SHO?
2. The organization of the authenticating user can now be used to check against the list of SP/institution specific LOA\'s.
3. The previous check can be removed (determineInstitutionsByIdentityNameId). Or are institutions outside of the current idp\'s SHO also relevant when selecting a viable token? (also see response in point 5)
4. This is a reaction to your first question. When SHO is missing in the assertion wouldn\'t it be wise to handle this as an unporocessable response. Showing the error message: Login response could not be processed. with a back to SP button. We could specifically log the SHO is missing in the assertion.
5. To validate I understand the implication of your second question. Let me ask a question of my own: Should an user be able to use token vetted by \'institution a\' for authentication for \'institution y\'? (Michiel Kodde - Dec 13, 2017)

[phavekes]

@michielkodde 

My Comments: @1: The SHO might not be there, this is not an error at this point. For getting the SHO, implement the same mechanism that is currently implemented in the SS. Generally see the attribute(s) being used for the purpose becoming configurable in the future. @4: This is the point to handle a missing SHO as an error, but only when the loa configuration for the SP has any entries other than __default__. @5: Currently a user is always vetted by their own institution, but this is a requirement that we will be relaxing in the future. The question is more, do we accept that the SHO attribute of a user changes? I\'d say that we disallow this for now. This means looking up the SHO of the user by NameID (just like now) and verifying that the SHO in the second_factor table matches that from the assertion that we just received. (Pieter van der Meulen - Dec 13, 2017)

[phavekes]

@1: Clear

@4: Clear @5: Clear (Michiel Kodde - Dec 14, 2017)

[phavekes]

I\'ve created a pull request that should fix the bug https://github.com/OpenConext/Stepup-Gateway/pull/127 (Michiel Kodde - Dec 14, 2017)

[phavekes]

Sitrep 2017-01-23

• PR #127 was merged to develop on Dec 18, 2017.
• @jodi still found an issue with the changes in the test environment.
• @pmeulen created a description and a flowchart covering the desired functional design of the LoA determination. (Michiel Kodde - Jan 23, 2018)

[phavekes]

Updated the tasks to cover the last leg of this story. (Michiel Kodde - Jan 23, 2018)

[phavekes]

Two pull requests are ready to be merged:

• https://github.com/OpenConext/Stepup-Gateway/pull/132
• https://github.com/OpenConext/Stepup-Middleware/pull/211 (Michiel Kodde - Jan 24, 2018)