Shibboleth Identity Provider 3.2.1 custom authentication configuration

Raymond Gardner r.gardner at ntta.com
Fri Jul 8 17:43:38 EDT 2016


> I'm hoping I can find some direction on a good approach to follow.

Yell at the SP? ;-)
[Raymond Gardner] I am also the SP.  Yelling at myself will not impress my boss.

I don't really think you could manage this now without a significant amount of custom code, essentially a new login flow.
[Raymond Gardner] I have already been looking at a new login flow.  I wanted to give aggregateAuthentication a chance but, that is not working for me.
I've seen a failover configuration option.  Sounds promising but how to do the database lookup upon failover.  Scott, you suggested JAAS in an earlier post.
I have not tried JAAS but I feel I will still have issues with a database lookup running in-between the "stacked" LDAP instances.

> To do the database lookup, I was thinking of using a custom bean 
> similar to the trim and lowercase beans already provided.
> 
> There is a transform bean, shibboleth.authn.Password.Transforms, but 
> that is for regular expressions.  I need one of these to do a database lookup.

There's simply nothing like this out of the box.
[Raymond Gardner] I was thinking I could extend the Transforms bean and provide a DBTransforms bean.
Then, configure the ExtractUsernamePasswordFromFormRequest bean to use my DBTransforms bean.
Or, better yet, just add a database lookup bean in the existing Transforms bean listing.  But, I'm not sure what that would look like.
    <!-- Apply any regular expression replacement pairs before validation. -->
    <!-- Why limit this to regular expressions? -->
    <util:list id="shibboleth.authn.Password.Transforms">
        <!--
        <bean parent="shibboleth.Pair" p:first="^(.+)@example\.edu$" p:second="$1" />
        -->
        <bean parent="shibboleth.Pair" p:first="select usernamePrime from table where username = '$1'" p:second="$1" />
    </util:list>

I do think the MFA support in 3.3 actually will work for this use case. It's less about MFA and more about orchestrating multiple login flows together. And the database lookup is basically just resolving an attribute, so that's all accounted for. Doesn't help you, but it's a useful benchmark for me that this crazy use case happens to be trivial with what I just finished building.
[Raymond Gardner] I think MFA sounds great.  I prefer to stay with the stable 3.2.1. release for now.
The database lookup will need to happen before authentication.  I believe attribute resolution happens after authentication.

Thanks!

****************************************************************
This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT America makes no warranty that this email is error or virus free. Thank you.
****************************************************************



More information about the users mailing list