shibboleth.authn.RemoteUser.externalAuthnPathStrategy bean definition

Losen, Stephen C. (scl) scl at eservices.virginia.edu
Tue Jan 17 11:52:52 EST 2017


Scott, thanks so much for your informative reply, it helps a lot.  I hate to be a pest, but I have one more question.  I think I will need to create multiple "principalToCheck" beans and put calls to each isAcceptable() method in the script.  Can I pass multiple beans to the script or do I need to create a collection (list? map?) out of these beans and pass the collection to the script?

How should I pass multiple "principalToCheck" beans to the script and then how does the script access them?

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu    434-924-0640


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, January 17, 2017 10:16 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: shibboleth.authn.RemoteUser.externalAuthnPathStrategy bean definition

> I would like to use the new feature introduced in IDP v 3.3 for RemoteUser
> authentication where the externalAuthnPath is returned by a bean of type
> Function<ProfileRequestContext,String>.  According to the wiki I must define
> a bean with the id
> shibboleth.authn.RemoteUser.externalAuthnPathStrategy.  Unfortunately I
> know next to nothing about Spring, etc., and I don't see an example in the
> wiki or in the 3.3 config files.

Learning Spring is simply not optional with this software, we had no choice to accomodate this degree of radical flexibility. There's no configuration format capable of handling it.

So my advice is to start reading the XML configuration docs and start looking at the existing files, in terms of becoming comfortable with the syntax.

> Basically I want to set the path based on the value of the authnContextClass.
> I am hoping I can do this in the proper XML config file (avoid java coding).

Scripts are still code, they just happen to be interpreted. It doesn't make much difference when the bean in question isn't reloadable via some subsystem like the resolver or whatever, debugging is about the same effort whether it's code or script, somewhat easier to an extent since a lot of the API will be enforced by the compiler.
 
> From snooping around in the 3.3 config files it looks like I need to use the
> bean factory-method="inlineScript".

<bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">

Example in authn/mfa-authn-config.xml and other places probably. The ProfileRequestContext is in the variable called input, and there's really nothing else supplied unless you inject it, an example of which is also in the same place.

>  Not sure how to get the
> authnContextClass from the ProfileRequestContext either, but I can keep
> snooping.

You should not be examining them directly and that would be extremely fragile given the ways they can be assigned to requests. Given a candidate AuthnContextClassRef, you wrap it in an AuthnContextClassRef principal, and evaluate the isAcceptable() method on the IdP's AuthenticationContext object.

<bean id="principalToCheck" parent="shibboleth.AuthnContextClassRefPrincipal" c_0:="contextclassref" />

<bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
	p:customObject-ref="principalToCheck">
<constructor-arg>
if (input.getSubcontext(
	"net.shibboleth.idp.authn.context.AuthenticationContext").isAcceptable(custom)) {
} else {
}
</constructor-arg>
</bean>

Approximately.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list