OPUserAuthentication

File(s): conf/authn/authn.properties
Format: Spring Properties

Overview

Authentication of users is obviously independent of OIDC (or CAS or SAML) with the exception of a couple of OIDC-specific notes.

User Interface

The RpUIContext lists the view "variables" that are populated from SAML metadata (and this extends to use of SAML metadata for OIDC client registration). That page also contains instructions how the attributes can be exploited in views.

When the other mechanisms for client registration are used, the following attributes are populated from OIDC client metadata.

Note that in the case of OPDynamicClientRegistration, that implies unauthenticated, external injection of some values and this certainly has the potential to be unsafe, though the data should of course be encoded for safety.

$rpUIContext.contactEmail(type): Corresponds to "contacts" field in OIDC metadata. Only the type "support" is currently supported.
$rpUIContext.informationURL: Corresponds to "tos_uri" field in OIDC metadata.
$rpUIContext.logo: Corresponds to "logo_uri" field in OIDC metadata.
$rpUIContext.privacyStatementURL: Corresponds to "policy_uri" field in OIDC metadata.
$rpUIContext.serviceName: Corresponds to "client_name" field in OIDC metadata, falling back to "client_id" if none is set.

If the OIDC metadata does not contain language-specific settings, the default language is currently "en".

ACRs

OIDC has the concept of an "authentication context reference" (acr) that is largely copied from SAML's <AuthnContextClassRef> construct with a couple of notable differences: only exact matching is supported and OIDC has the concept of both "essential" and "voluntary" matching. Essential matching behaves identically to exact matching in SAML, while voluntary matching doesn't have an analog in SAML and doesn't map well to the IdP's behavior in most cases.

A utility bean named shibboleth.OIDCAuthnContextClassReference is provided that allows the necessary custom Principal objects to be defined to asociate authentication flows, results, and relying party overrides with particular "supported" Principal types in the usual manner.

Examples

If you wanted to attach the REFEDS MFA profile value to an MFA authentication flow, you could set the following property to cover SAML 2.0 and OIDC:

conf/authn/authn.properties

idp.authn.MFA.supportedPrincipals = \
	saml2/https://refeds.org/profile/mfa, \
	oidc/https://refeds.org/profile/mfa

If you wanted to force the use of that same profile via a RelyingParty override (by name):

conf/relying-party.xml

<bean id="ForceMFA" parent="RelyingPartyByName">
	<constructor-arg name="relyingPartyIds">
		<list>
			<value>https://oidc.example.org</value>
			<value>https://oidc2.example.org</value>
		</list>
	</constructor-arg>
    <property name="profileConfigurations">
        <list>
            ...
            <bean parent="OIDC.SSO">
				<property name="defaultAuthenticationMethods">
					<bean parent="shibboleth.OIDCAuthnContextClassReference"
						c:classRef="https://refeds.org/profile/mfa" />
				</property>
			</bean>
            ...
        </list>
    </property>
</bean>