How to define PreviousSession as authentication method in shibboleth idp4

[iljkr at tiscali.it]

Il 05.12.2022 20:15 Cantor, Scott ha scritto: 

>> 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




VOUCHER CONNETTIVITÀ per P.IVA e PMI: internet a canone 0 per 48 mesi. ATTIVA ORA
 https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/?r=TS00000A00025&dm=link&p=tiscali&utm_source=tiscali&utm_medium=link&utm_campaign=voucherbusiness&wt_np=tiscali.link.footermail.voucherbusiness.btb..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221206/15529516/attachment.htm>