How to define PreviousSession as authentication method in shibboleth idp4

[Cantor, Scott]

>Do you know where I can find a practical, simple, example in the
> documentation of a basic SSO working configuration?

A "basic" configuration does SSO automatically. You're not asking for something basic, you're asking about how to limit the use of SSO in more complex ways.

V2 did not support what you're asking about, at least not generally. Perhaps you cooked something up but I doubt that it worked the way you're thinking it did, it likely had all sorts of gaps in the behavior.
 
> For example, if I wanted to define simple rules like that:

That's far from simple. Grouping SPs like that is not a typical thing to do, and there isn't any straightforward way to do it because it requires detecting something that happened during an earlier request and preserving some evidence of it for later, and not just something that's happening during a new request.

That requires logic operating at both ends of the process, while building authentication results and testing for reuse of results.

The unfortunate asnswer is that I can't help you much on list. This would be a member support request, it's much more advanced than anything I could get into on list

If I try to explain it in general terms it won't make much sense, but FWIW...

You would have to define custom AuthnContextClassRef principals that represent the different "groupings" that are possible and get them attached to the AuthenticationResult objects being built by the login flow(s) you're using.

That's not an easy thing to do because it would have to be done dynamically based on the group to which the "current" SP belongs to. How I would do it would probably depend on which login flow(s) were being used.

Then I'd have to craft what are called "reuse condition" beans in Java or via scripting to attach to the login flow(s) that would be programmed to check the existing results for whether they contain particular custom Principals or not. Reuse conditions aren't that hard, but that particular requirement is not trivial to implement.

I'd probably end up defining relying party overrides as a convenience, to attach a general label to the SP groupings that I could check for in the right places to make the scripting a bit simpler.

Depending on how much you cared about the AuthnContextClassRef in the assertions coming back there are some ways to drive some of this without as much special logic.

I can imagine some ways to implement this as a sort of generic feature with a more intrinsic configuration that's explicitly about grouping services for this kind of purpose, but it's not trivial, so I can't promise we can do it immediately. But you can certainly request it in Jira.

-- Scott