3.3 SNAPSHOT: AuthN resolveAttribute not activating authn flow
Michael A Grady
mgrady at unicon.net
Mon Oct 24 18:38:07 EDT 2016
> On Oct 24, 2016, at 4:45 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
>
> I think this is the change involved:
>
> https://issues.shibboleth.net/jira/browse/IDP-980
>
> It fits your situation. I will have to review the change to see if anything there isn't making sense to me, but I want to emphasize a point here:
>
> If the request does not contain, either explicitly or via profile configuration, a requirement for how authentication should be done, you cannot make assumptions or try and trick the system into forcing use of particular methods. It's hopeless, fundamentally. It wants to do SSO. If you don't want SSO, then request a principal type that will require some additional step (which you can do dynamically now in 3.3 also). It's really that simple.
>
> I also need to be clear that while it's probably not documented yet, all the stuff you're using is going to be deprecated, either in 3.3 or the next release. It's definitely all gone in 4.0. Initial authn, that attribute hack, all of it. Don't use it once the new version is out. All of that was a horrible mess and I deeply apologize inflicting it on people. Anything using that stuff should be ported to the MFA flow or dumped.
>
> I will be very clear on that in the documentation, it's just not appropriate to do all that prior to release.
>
> Anyway, yes, it changed a number of months back, and no, I'm not 100% sure if I think it's right at the moment or not.
>
> -- Scott
>
If what the above is saying is that one will not be able to use the value of the "eduPersonAssurance/assurance/whatever name one used for that attribute" to force another factor (e.g. Duo) to be used (and current SSO session to NOT be sufficient), then you will greatly slow down adoption of 3.3. Any number of institutions drive the signaling of Duo/another factor thru logic in the resolver to calculate a value for that attribute.
--
Michael A. Grady
IAM Architect, Unicon, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://shibboleth.net/pipermail/dev/attachments/20161024/19d1f57c/attachment.sig>
More information about the dev
mailing list