How to configure multiple RemoteUser Auth URLs on IDP v3 ?

[Cantor, Scott]

On 4/20/16, 6:32 PM, "users on behalf of Losen, Stephen C. (scl)" <users-bounces at shibboleth.net on behalf of scl at eservices.virginia.edu> wrote:



>Here is how I set up "enhanced" login on IDP v2 in handler.xml

There is no direct equivalent, and it isn't really something you can do easily without learning at least some minimal Spring Web Flow to be able to copy and adapt the existing flows. It's mostly cut and paste more than really learning it, but it isn't trivial.

>We configured the app on the SP to request the AC class
>urn:oasis:names:tc:SAML:2.0:ac:classes:EnhancedNetBadge

Aside from your question, that's inappropriate, you can't create URNs in a namespace you don't own, and you don't own that namespace.

>I've been reading the IDP v3 wiki and am having trouble figuring out how to do this.  Obviously I need to configure webapp/WEB-INF/web.xml but I don't think I can specify the AC class in that file.  Maybe somewhere under conf/authn ?

Separating this into two parts, if you establish multiple login flows to use, you associate those flows in the configuration with a set of supportedPrincipals that include the AuthnContextClassRef values that a given flow supports, and then the system will mostly do the right things automatically to decide which one(s) to use for a request.

The documentation attempts to cover most of that in the AuthenticationConfiguration and AuthenticationFlowSelection topics.

The other part is the problem. There is no second flow for you to enable and associate with the other context class Principal, because the RemoteUser flow is only able to use a single URL. What you have to do is copy it and create a separate version with different settings under a different flow ID. There's not really any documentation on that, and the end result is somewhat of a layer violation because it will end up relying on implementation details that could change, so it's a problematic approach.

There isn't much to the RemoteUser flow, and it can copied easily enough into a user flow in flows/authn/ and then you can make changes to, e.g. the servlet path that it's redirecting to, along with the corresponding additions to web.xml.

One way around that is to adapt the existing External login flow, as is, and configure it to serve as your second/special flow. The RemoteUser flow is really just a specialization of External. If you configure the External flow's redirect to a copy of the RemoteUser auth servlet running at a separate path, that would be a way to end up with a second copy of the RemoteUser flow without actually having to create it yourself.

-- Scott