Specify a default authentication context in Relying Party config
Cantor, Scott
cantor.2 at osu.edu
Mon Nov 30 22:00:20 EST 2015
On 11/30/15, 9:52 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:
>Thanks, I see you changed that example.
I just want to be defensive and avoid shortcuts if I'm not sure they're stable.
>Stepping aback, why is it that one sets the Methods and not the Contexts?
SAML 1 and 2 don't represent these things with the same type of data so it's not apples and apples. That was a bug in V2.
The property here returns List<Principal>. The setters are specific to the type of object appropriate to the profile.
> Given that the relying party config is serving in place of the SP sending a RequestedAuthnContext?
That's only true of SAML 2, there isn't any functionality like that in SAML 1, and the objects that have to be compared aren't of the same type.
> Was that just to minimize changes from v2, or some more fundamental reason/"underlying model"?
Every protocol has its own mechanics and terminology. OpenID included, I would imagine. The "engine" underneath doesn't know about any of them, so the comparisons its making have to allow for different kinds of Principal objects to be compared. The only contract is that they be Principal subclasses.
-- Scott
More information about the users
mailing list