SP v4 alpha2 and discoveryURL ?

[Scott Cantor]

> Noticed a bit strange behaviour on alpha2 and discoveryURL:

If there's a use case for an Application, there probably needs to be something else developed to handle it. Applications are an absolutely terrible feature. Avoid them in all cases. That's not changing, it's becoming more important to keep in mind.

Note that while Agents are in general able to operate pretty unware of details, the authority thing is one setting that may still need to be tunneled up, and we still allow for that. You don't need or want to use Applications to deal with that, it's a far worse approach for everybody concerned because the Agent config ends up being more complex to make use of it than it is to just have the authority setting applied to the content there. It's more obvious what's happening for one thing.

> Should the entityID on the DS url be
> p:issuer="https://sptest1.uef.fi/sp" and not default sp.issuer ?

I would expect so but once you even go near Applications, everything becomes unbearably hard to make work. I will have to test all that again to find all the bugs, it's not been a priority.

> It's not a problem if agent and application must use either discovery
> or p:authenticatingAuthority, this was just a test, but should
> discovery work for application ?

The problem is that "null" means "inherit", kind of. I don't know why issuer isn't being set properly because that's being explicitly overridden, but you can't override a value set to "something" to "nothing" unless you flip to the "don't inherit anything" parent bean provided for that purpose.

I would be more bothered by it if I wanted that feature to get used, but I don't, so I don't know that I'm inclined to try and work around it and make things even worse.

> There are one or two SPs that use applications(different entityID and
> different attributes (and logging on IdP which service accessed)).

Using different issuer values doesn't require all that work (then or now). The main thing that people want is usually session boundaries (*) so that people get sent to login again when they cross some boundary.

I believe, but have not tested, that the most direct way to get that work is going to be overriding the session cookie name in the Agent. There's a setting for that, and I think it will effectively partition things in the same way it did/does when the applicationId is set. I'll set a reminder to check on that and I can fix it if it's not doing what I think it is.

(*) But even then, what you really should do is use a vhost. Virtual hosts are free now, that all changed when SNI became universal and certificates became free and automated.

> I'm assuming that scripted/AutomatedIssuerGeneration could be used to
> use different p:issuer for agent and agent/application.
> Something like:
> <bean id="custom.IssuerStrategy"
> parent="shibboleth.ContextFunctions.Scripted"
> ...
> (script returns different issuer based on agentRequestContext /
> getAgent() / getApplication())

Well, not for *that* reason, no, the whole point of that feature is to avoid the Application distinction to begin with, though it certainly could be used to automate issuer values based on, say, Agent IDs, reducing some extra configuration settings. One can imagine all sorts of conventions there since the agent ID is pretty arbitrary and is distinct from the "username" they use to send their requests.

A similar function for deriving the authority value might address the problems overriding "something" to "nothing", but for most people, the complexity of doing that at all is going to be beyond what they can handle.

I can picture ways to solve the "set authority to null" problem more elegantly, but my concern is that every bit of work done to make that feature more viable just encourages people to go down a very bad road.

There are, always, betters ways to solve these issues than Applications. It only comes up with custom apps because anything "packaged" is never going to have the level of integration and awareness needed, and with custom apps, there are simply better ways to organize the URL space to solve things.

But I think the sessionCookieName trick is what will usually help. That gets you the "new login when you go from /foo to /bar in a web site" behavior. The only trick then is what in particular is supposed to be different when it does. If it's the IdP to use (or not having one), just stuff it in the "authority" setting in the same place you put the sessionCookieName setting in the Agent.

Once I test it out, I'll write up some Agent examples for that.

I'll check into why issuer isn't being overridden properly, that much should work.

-- Scott