<div dir="ltr">For those interested, here are the steps I followed to add a  two-factor authentication for Shibboleth IDP v3.<div>This was done for a very constrained environment - where the IDP was used internally to provide a single sign on environment to couple of application. The two-factor authentication was achieved by a product called Telesign which sends an SMS code that is then enter by the user in the login sequence and verified by Telesign.</div><div><br></div><div>The design of the authentication was to complete the initial authentication sequence against the LDAP, then the user is presented with a new screen which they enter a security code sent by Telesign. If they fail, they will remain on that screen and they can try again. The user is also presented with an option to generate a new code, which will send a new code. Once the user enters a valid security code, then authentication flow completes.</div><div><br></div><div>Firstly, we got a normal authentication sequence working with Shibboleth IDP v3. The user was authenticating against an LDAP server</div><div>using the Password authentication flow - configured in idp.authn.flows.</div><div><br></div><div>The second step, was given we were building on this existing flow was make a copy of this existing flow. The flows are defined in %IDP/system/flows/authn and each flow consists of two files - the *-authn-flow.xml and*-authn-beans.xml. The flow file defines the Spring Web flow and the beans files defines the Spring beans (underlying java classes) used to implement the flow.</div><div><br></div><div>Rename your new flow as appropriate. You need to add this new flow to the system and I added changes conf/authn/general-authn.xml and  system/conf/webflow-config.xml. You can also change idp.authn.flows to use your new flow. At this stage, you should be running a copy of the previous authentication flow but the underlying beans are still those from the previous flow.</div><div><br></div><div>You need to have downloaded the Shibboleth IDP source code. By looking at the *-authn-beans.xml code, you can work out the class(es) used. Essentially you want to look at that relevant code and then create a new class for your flow based on the current class(es) you are using. You should have references to the Shibboleth -api classes but shouldn't reference existing -impl classes in your new class. Once you have built your new class, you can change the references in *-authn-beans.xml to refer to your new class. Add your new class to %IDP/edit-webapp , rebuild and redeploy the shibboleth IDP. So now you are running your own flow with your own underlying class.</div><div><br></div><div>You can now start extending the new flow which isn't too hard - just need to read up Spring Web flows and flow the existing code as an example.  If you need to have attributes from an LDAP authentication - please see <a href="https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AttributeRetrieval" style="font-size:12.8000001907349px" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AttributeRetrieval</a> of how to do it. I required the mobile number from the  ldap before I could generate the call to send the SMS message.</div><div><br></div><div>I added 3 states and 1 views to my flow. The first state generate the SMS request from Telesign, then the view to enter the security code, then a state to exact the code from the form and finally a state to validate the security code with Telesign. To communicate across the states I created by only subcontext off the authentication Context. The new functionality is added to the new class that was created for this flow.</div><div><br></div><div>Hopefully this might be useful for someone trying to do something similar. Happy to answer any questions you might have.</div><div><br></div><div>Regards</div><div>Ranil</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 May 2015 at 01:59, 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"><span class="">On 5/10/15, 7:46 PM, "Ranil De Silva" <<a href="mailto:ranil.desilva@industrieit.com">ranil.desilva@industrieit.com</a>> wrote:<br>
><br>
>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.<br>
<br>
</span>I hadn't actually remembered that you could use the authentication to LDAP to get that data, but you should bear in mind that your flow is then tied to LDAP only. I'm sure that's fine for your use case, just saying more generally that it's a potential limitation.<br>
<span class=""><br>
>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!<br>
<br>
</span>That's nice to hear particularly given the lack of documentation right now for what you're doing. If you have the time to even lightly sketch out what you had to do in the wiki or in an email, it would be helpful to others.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div><br>
</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>