<div dir="ltr">Hi Scott,<div><br></div><div>Thanks for your help on this - I managed to implement a new flow to handle the two factor authentication with Telesign. It was reasonable straightforward. The hardest part was actually getting the mobile phone from the AD LDS instance which Daniel Fisher provided a nice solution to.</div><div><br></div><div>You and everyone working on this product have done a great job and support is easily better than most commercial products out there - so thank you very much!</div><div><br></div><div>Kind regards</div><div>Ranil<br><div class="gmail_extra"><br><div class="gmail_quote">On 28 April 2015 at 12:26, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please take any follow up to the dev list.<br>
<br>
On 4/28/15, 1:35 AM, "Ranil De Silva" <<a href="mailto:ranil.desilva@industrieit.com" target="_blank">ranil.desilva@industrieit.com</a>><br>
wrote:<br>
<br>
<br>
><br>
<span>>So Telesign sends an SMS to the user with the 2-factor code that they<br>
>need to enter on the screen. For that to work, the user must have been<br>
>authenticated against the LDAP first so we can retrieve their mobile<br>
>phone number from their LDAP entry. So the JAAS module will not work for<br>
>me.<br>
<br>
</span>Yes, as I said.<br>
<span><br>
>So creating a new flow is the approach I need to take. What I am not<br>
>clear about at the moment, is how to integrate the new flow into<br>
>Shibboleth.<br>
<br>
</span>There are no docs on it yet, it's next on my list but only some basic<br>
guidance, I don't have time to build extensive development material. There<br>
are brief notes for now in the authentication topic about how to define<br>
custom flows and where to put them (and how to name them), and how to<br>
define new flows to the system in general-authn.xml. Once I have something<br>
separate written I'll move that over and flesh it out.<br>
<span><br>
> In particular should I be using net.shibboleth.idp.authn.* classes as<br>
>the basis of my flow. Ie should model in on the existing flows or should<br>
>I create a new flow with my own libraries and somehow inject it all into<br>
>Shibboleth or something in between.<br>
<br>
</span>Any classes in idp-authn-api and other -api modules are fair game to build<br>
on and are subject to our versioning and API policies, which basically<br>
means your plugins are going to work until at least V4. Anything you<br>
choose to use from idp-authn-impl or other -impl modules is not guaranteed<br>
to be stable across any releases or patches, period. In other words, I<br>
wouldn't do it, I'd copy them into your own packages and library project<br>
if you want to use them as examples.<br>
<br>
There are some odd module naming exceptions we have to clean up that make<br>
it more confusing than it should be, but nothing very relevant to login<br>
flows.<br>
<br>
If you want to write a login flow with SWF, you are going to have to look<br>
at how our flows work and build consistently with them. Login flows aren't<br>
very long or complex relatively speaking, but you have to inherit from the<br>
right parent flows and do error handling in some very specific ways that<br>
are built into those parent flows.<br>
<br>
If you do not want to use SWF, then you're not building a flow, you're<br>
using the External login flow and implementing your own servlet or<br>
whatever outside of SWF. That is the only way to interface to the login<br>
process without using SWF.<br>
<span><br>
>My flow will be similar to the password-auth-flow, except after the<br>
>user/password has been validated, I need to extract the mobile# and send<br>
>the sms code, then we go to a new view, where the user has to enter this<br>
>code. Once the code has been validated we are done. If the code fails we<br>
>stay on that screen.<br>
<br>
</span>Yes, I understand. It's not a terribly complex one because you can use<br>
views and wait for user entry, there's nothing asynchronous happening.<br>
<div><div><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><div><div dir="ltr"><br></div></div>
</div></div></div>

<br>
<div><font face="Arial, Helvetica, sans-serif" size="2"><br></font></div><font face="Arial, Helvetica, sans-serif" size="2">This email is confidential and intended solely for the person(s) to whom it is addressed.</font>