While thinking of a PoC design of FedCM at our university IdP, we collected some considerations for the usage of FedCM in the R&E context.
This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
LoginUrl in R&E
In the R&E sector, IdPs might not allow users to authenticate at the IdP directly. For example, the IdP of our university (sso.hm.edu) does not offer a loginUrl such as "sso.hm.edu/login" that users can directly navigate to in order to authenticate. Instead, the usual SAML/OIDC login flow is only executed after a redirect to the IdP from a specific RP.
Depending on the federation protocol used, there might be different solutions that R&E IdPs can consider:
In Shibboleth, the predominant R&E IdP/SSO implementation, an "Unsolicited Login" exists.
In this mode, the user directly visits the IdP, supplying some RP's providerId via URL parameters, i.e., the clientId sent in the FedCM call
Example: https://sso.hm.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=https://moodle.hm.edu/shibboleth
However, this mode is less secure, sometimes disabled, and designated as optional in the SAML2 specification.
R&E IdPs could integrate a separate RP for this exact purpose.
Shibboleth as well as other popular IdP implementations would need to have such an option available out of the box.
This option might be used for both SAML and OIDC based IdPs.
In order to make FedCM usable for R&E federations that do not offer such a solution, the "wayf" mode might be considered.
Step 5 in FedCM in Multilateral Federations
In our understanding, Step 5 of the FedCM flow serves two purposes:
Fetching client metadata about the RP from the IdP, e.g., URLs for the TOS and privacy policy.
Ensuring that the RP is registered and trusted by the IdP.
In multilateral federations, RPs are not always explicitly registered with the IdP. Therefore, the IdP would need to resolve the client metadata for the specific RP first. This process is different depending on the underlying federation protocol.
As an alternative, RPs that are part of multilateral federations could provide their TOS and privacy policy directly to FedCM.
Even though this is not FedCM specific, we believe that it is vital to define what actions the IdP should perform in this step.
SAML2
In SAML federations, the IdP usually has (and regularly updates) extensive XML files containing the metadata of all RPs per federation, e.g., for all RPs in their national federation and in eduGAIN. The IdP could simply find the right metadata based on the RP's clientId the browser sends, if the clientId is the same as the entityId used in the federation. Since this approach is based on data from a trusted third party (e.g. eduGAIN), no requests from the IdP to the RP are necessary. Therefore, the user's IdP are not disclosed to the RP.
OpenID Federation
In OpenID Federation, the process of retrieving metadata for a specific RP and validating a trust relationship is more dynamic. This normally includes the generation of a trust chain, starting at the RP's well-known/openid-federation endpoint and ending at a trusted third party (trust anchor; e.g. eduGAIN). However, if the IdP issues a request to the RP's well-known endpoint, an RP could correlate this request with the user's running browser session.
This presents a privacy issue and must be avoided.
Using the trust chain as described in this issue does not leak this information, but requires the RP to provide the browser with its trust chains in the FedCM call. Alternative privacy-preserving approaches to avoid disclosing the IdP to the RP must be considered, for example by resolving trust indirectly via the trust anchor.
While thinking of a PoC design of FedCM at our university IdP, we collected some considerations for the usage of FedCM in the R&E context. This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
LoginUrl in R&E
In the R&E sector, IdPs might not allow users to authenticate at the IdP directly. For example, the IdP of our university (sso.hm.edu) does not offer a loginUrl such as "sso.hm.edu/login" that users can directly navigate to in order to authenticate. Instead, the usual SAML/OIDC login flow is only executed after a redirect to the IdP from a specific RP.
Depending on the federation protocol used, there might be different solutions that R&E IdPs can consider:
https://sso.hm.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=https://moodle.hm.edu/shibbolethHowever, this mode is less secure, sometimes disabled, and designated as optional in the SAML2 specification.In order to make FedCM usable for R&E federations that do not offer such a solution, the "wayf" mode might be considered.
Step 5 in FedCM in Multilateral Federations
In our understanding, Step 5 of the FedCM flow serves two purposes:
In multilateral federations, RPs are not always explicitly registered with the IdP. Therefore, the IdP would need to resolve the client metadata for the specific RP first. This process is different depending on the underlying federation protocol. As an alternative, RPs that are part of multilateral federations could provide their TOS and privacy policy directly to FedCM. Even though this is not FedCM specific, we believe that it is vital to define what actions the IdP should perform in this step.
SAML2
In SAML federations, the IdP usually has (and regularly updates) extensive XML files containing the metadata of all RPs per federation, e.g., for all RPs in their national federation and in eduGAIN. The IdP could simply find the right metadata based on the RP's clientId the browser sends, if the clientId is the same as the entityId used in the federation. Since this approach is based on data from a trusted third party (e.g. eduGAIN), no requests from the IdP to the RP are necessary. Therefore, the user's IdP are not disclosed to the RP.
OpenID Federation
In OpenID Federation, the process of retrieving metadata for a specific RP and validating a trust relationship is more dynamic. This normally includes the generation of a trust chain, starting at the RP's well-known/openid-federation endpoint and ending at a trusted third party (trust anchor; e.g. eduGAIN). However, if the IdP issues a request to the RP's well-known endpoint, an RP could correlate this request with the user's running browser session. This presents a privacy issue and must be avoided. Using the trust chain as described in this issue does not leak this information, but requires the RP to provide the browser with its trust chains in the FedCM call. Alternative privacy-preserving approaches to avoid disclosing the IdP to the RP must be considered, for example by resolving trust indirectly via the trust anchor.