Help with 2-factor authentication with Telesign

[Ranil De Silva]

For those interested, here are the steps I followed to add a  two-factor
authentication for Shibboleth IDP v3.
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.

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.

Firstly, we got a normal authentication sequence working with Shibboleth
IDP v3. The user was authenticating against an LDAP server
using the Password authentication flow - configured in idp.authn.flows.

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.

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.

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.

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
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AttributeRetrieval
of
how to do it. I required the mobile number from the  ldap before I could
generate the call to send the SMS message.

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.

Hopefully this might be useful for someone trying to do something similar.
Happy to answer any questions you might have.

Regards
Ranil



On 12 May 2015 at 01:59, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 5/10/15, 7:46 PM, "Ranil De Silva" <ranil.desilva at industrieit.com>
> wrote:
> >
> >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.
>
> 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.
>
> >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!
>
> 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.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>

-- 

This email is confidential and intended solely for the person(s) to whom it 
is addressed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150521/ab3948ec/attachment.html>