How to define PreviousSession as authentication method in shibboleth idp4

[iljkr at tiscali.it]

  Hi Scott,
thanks a lot for the detailed answer.

I have just two
considerations to avoid misunderstandings on v2 and v4 versions.

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

We have in production the idp shibboleth v2 and
SSO works, but if we remove the LoginHandler when we define previous
session like AuthenticationMethod the SSO stop to works. If SSO is
enabled by default we probably have some customization that disables it
but at the moment we don't understand which one. 

For the future we
plan to replace v2 with v4 and are working on the migration. And for now
we are using idp V4 only in development environment. It seems that in
the migration we inherited that problem we had in version 2. SSO doesn't
work and the login handler that we use to fix the problem (perhaps
improperly?) in the v2 has been removed in v4 and for now we have idp4
without SSO. A new feature (using v4) that we would like to bring into
production, that arises from market needs, was that of being able to
create groupings of SPs, I didn't think it was a complex issue.

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

It
would be very useful..

CP.

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/3edad038/attachment.htm>