Handling LOA-based authentication context classes in Shibboleth IdP

[Guillaume Rousse]

Hello list.

According to IdP documentation on authentication flow selection[1], the 
IdP handles request requiring a specific authentication context class by 
comparing the request requirements with current user session (if any) 
first, and with the list of supported principals for every available 
login flow second. A request requesting "https://refeds.org/profile/mfa" 
context class, for instance, will immediatly result in a error response 
with urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext status code, if 
none of the available login flow has this value specified in its list of 
supported principals.

This works fine when those context classes only express an 
authentication assurance level, based on authentication mechanisms, as 
request requirement handling occurs before user authentication.

However, eIDAS SAML message format specification [2] mandates usage of 
authentication context classes mixing authentication and identity 
assurance levels:
- http://eidas.europa.eu/LoA/low
- http://eidas.europa.eu/LoA/substantial
- http://eidas.europa.eu/LoA/high

Given than identity assurance level is usually user-specific (typically, 
employees have higher identity assurance levels than students or 
contractors), this would make handling the requirement more complex, as 
the IdP would have to:
1) find a compatible login flow
2) run the flow, to authenticate the user
3) retrieve a minimal list of attributes
4) check if it matches request requirements

AFAIK, 3 and 4 require non-trivial post-login processing, similar to 
subject canonicalization, and usage of scripted procedures. Or am I 
missing something ?

Regards
-- 
Guillaume Rousse
Direction des Services Applicatifs
RENATER - Paris

[1] 
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505253/AuthenticationFlowSelection
[2] 
https://ec.europa.eu/digital-building-blocks/sites/download/attachments/467109280/eIDAS%20SAML%20Message%20Format%20v.1.4.1_final.pdf?version=1&modificationDate=1729176505264&api=v2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20260623/303c6f89/attachment.p7s>