In session Step-Up Authentication

[zaic20]

Dear all, I have a quick question.

I saw that is possibile to configure step-up authentication (https://github.com/zmartzone/mod_auth_openidc/wiki/Step-up-Authentication) but in the example below, I want to be sure that when a user requests /admin has already been authenticated by /user and has a valid session. So the question is, can the module check the validity of an existing session before to invoke the step-up flow?

Thanks in advance!!!

<Location /user>
AuthType openid-connect
Require claim acr:1factor
Require claim acr:2factor
Require valid-user

<Location /admin>
AuthType openid-connect
Require claim acr:2factor
OIDCUnAutzAction auth
OIDCPathAuthRequestParams acr_values=2factor
Require valid-user

[zandbelt]

not sure what you're looking for: if there's an existing session, the module would check that the required claims exist, and if they're not there, redirect for authentication; are you asking what the module should do if a session does not exist?

[zandbelt]

you could configure a different redirect endpoint to intercept that, but I don't think it should be necessary: what are you trying to achieve?

[zaic20]

Thanks Hans, I try to explain better what I want to achieve:

1. The user makes a request asking a resource, for example /user/index.html, that is inside a Location /user that is protected by the claim "acr:1factor"
   (the OIDC flow has been intentionally simplified)
2. The user is redirected to the OIDCProvider for authentication that generates the token with required claim inside ("acr:1factor")
3. The module allows the user to access to all the resources under /user for the duration of the session
4. At one point the user (with an existing session) asks to access to /admin/index.html, that is inside a Location /admin that is protected by the claim "acr:2factor" (In the mean time the session on the OIDCProvider is expired but the session on the module not and is still valid)
5. The user is redirected to the OIDCProvider for authentication (because the token doesn't contain the the claim acr:2factor), but the OIDCProvider doesn't know that the user has already a valid session on the module and, must ask again to the user first factor and then second factor (due to the fact that the scope, or a request parameter, is 2factor) and at the end generates the token with required claims inside ("acr:1factor" and "acr:2factor")
6. The module allows the user to access to all the resources under /admin and /user for the duration of the session

At step 5 I want to avoid that the OIDCProvider asks to the user the first factor even if the session on OIDCProvider is expired (for example trusting the fact that if the module is making the authentication request with the specific scope or parameter (2factor), the module has already checked that the user is authenticated with the first factor and has a valid session).

Thanks so much for your help and availability!!!!

[zandbelt]

at step 5. the OIDC Provider can just implement this behaviour based on the availability of acr:2factor in the scopes in the request (and the omission of acr:1factor in the there); also, be aware that the 2 Require directives are a logical "or" so I think it works as you describe already

[zaic20]

Thanks Hans, this is what I saw implementing the flow in this way (based on the availability of acr:2factor in the scopes), I checked that if the user, without any active session at all and as first request, accesses directly to /admin/index.html will be authenticated only with one factor (actually the second e.g. OTP via SMS) and can access to the resources /admin/index.html and /user/index.html....but this is wrong because the user hasn't completed 2 factors authentication (e.g. PWD + OTP via SMS). Please fell free to correct me if I'm doing something wrong.

[zandbelt]

that's behaviour that the OP implements and hence should be fixed at the OP: instead of interpreting 2factor as "2nd-factor only", it should interpret it as "2 factors required"; you could also invent different scopes to trigger the different behaviours