[EXT] Learning to develop an IDP extension

[Yeargan, Yancey]

I appreciate the clarification. I won't claim to fully understand those distinctions at this time, but expect it to make more sense after looking over the code and reviewing the documentation in more depth. We have very limited use of RSA SecurID and do not anticipate using that with Shibboleth, but I understand what you mean about providing the two factors at the same time with SecurID.

From what I understand so far of the Microsoft solution, I think the expectation is that the IDP will perform standard username/password authentication first, and then the Microsoft server has a few user-selectable options for the next step. 

The simplest option appears to be a voice call to the user's phone, which the user must answer and press the "#" key to authorize. Another option is sending a code via SMS or e-mail message. 

For that first option, I would expect the IDP to simply wait for a response from the Microsoft server (and timeout for no response). For the latter option, I would expect the IDP to present a form to the user to receive the code, and then for Shibboleth to confirm the code is correct with the Microsoft server (via SOAP API).

At this point, my goal is to present proof-of-concept demonstrations (which may require multiple approaches and separate development projects). Management will then review the options and let me know which they want to use. Nothing is set in stone yet.

— Yancey


> On Mar 27, 2018, at 4:52 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 3/27/18, 5:46 PM, "users on behalf of Yeargan, Yancey" <users-bounces at shibboleth.net on behalf of Yancey.Yeargan at untsystem.edu> wrote:
> 
>> At this time, I expect it to be second-factor only; though I would be foolish to not anticipate scope creep in the future.
> 
> It's not a scope matter, it's a "this is what you must do and not do other things" issue. You will end up with a mess and it will be broken if you try and do more than just what it's required to do. The first factor is not the job of that flow.
> 
> The contrast is RSA SecurID, which is actually MFA, in one token. It can only be done by supplying both factors at once to the RSA library and so it's implemented in one flow. It's one system handling both factors so it's one flow.
> 
> Most "MFA" solutions today are not MFA, so the new flow's job is not MFA, it's to implement the new factor. The IdP's MFA flow is what ties them together, not your extension.
> 
> -- Scott
> 
> 
> -- 
> For Consortium Member technical support, see https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=01%7C01%7CYancey.Yeargan%40untsystem.edu%7C73ace9436637400069cb08d5942d07ee%7C70de199207c6480fa318a1afcba03983%7C0&sdata=rU564XPvwFBq5X1%2BaNVnmBgyV28SfnxWdTG98wgUoPo%3D&reserved=0
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net