Help with 2-factor authentication with Telesign

[Cantor, Scott]

Please take any follow up to the dev list.

On 4/28/15, 1:35 AM, "Ranil De Silva" <ranil.desilva at industrieit.com> 
wrote:


>
>So Telesign sends an SMS to the user with the 2-factor code that they 
>need to enter on the screen. For that to work, the user must have been 
>authenticated against the LDAP first so we can retrieve their mobile 
>phone number from their LDAP entry. So the JAAS module will not work for 
>me.

Yes, as I said.

>So creating a new flow is the approach I need to take. What I am not 
>clear about at the moment, is how to integrate the new flow into 
>Shibboleth.

There are no docs on it yet, it's next on my list but only some basic 
guidance, I don't have time to build extensive development material. There 
are brief notes for now in the authentication topic about how to define 
custom flows and where to put them (and how to name them), and how to 
define new flows to the system in general-authn.xml. Once I have something 
separate written I'll move that over and flesh it out.

> In particular should I be using net.shibboleth.idp.authn.* classes as 
>the basis of my flow. Ie should model in on the existing flows or should 
>I create a new flow with my own libraries and somehow inject it all into 
>Shibboleth or something in between.

Any classes in idp-authn-api and other -api modules are fair game to build 
on and are subject to our versioning and API policies, which basically 
means your plugins are going to work until at least V4. Anything you 
choose to use from idp-authn-impl or other -impl modules is not guaranteed 
to be stable across any releases or patches, period. In other words, I 
wouldn't do it, I'd copy them into your own packages and library project 
if you want to use them as examples.

There are some odd module naming exceptions we have to clean up that make 
it more confusing than it should be, but nothing very relevant to login 
flows.

If you want to write a login flow with SWF, you are going to have to look 
at how our flows work and build consistently with them. Login flows aren't 
very long or complex relatively speaking, but you have to inherit from the 
right parent flows and do error handling in some very specific ways that 
are built into those parent flows.

If you do not want to use SWF, then you're not building a flow, you're 
using the External login flow and implementing your own servlet or 
whatever outside of SWF. That is the only way to interface to the login 
process without using SWF.

>My flow will be similar to the password-auth-flow, except after the 
>user/password has been validated, I need to extract the mobile# and send 
>the sms code, then we go to a new view, where the user has to enter this 
>code. Once the code has been validated we are done. If the code fails we 
>stay on that screen.

Yes, I understand. It's not a terribly complex one because you can use 
views and wait for user entry, there's nothing asynchronous happening.

-- Scott