Need some authn config strategy help.

[O'Dowd, Josh]

Hello again,

I am needing some advice on a strategy/approach to take with IDP 3 regarding authn configuration/customization.  I do have some intermediate experience with spring and spring-web-flow.  I am having trouble figuring out a safe clean way to migrate our current idp2 login process(s) to idp3.

Our requirement using LDAP password authentication at login page is as follows:


1.        If LDAP response is 'password must change' or 'expired' then sub-flow to password change-form (user redirect to requested service is not allowed until password is valid).

a.       Upon successful completion of the form, user is granted authentication and redirected to service requested.

2.       If LDAP response is password expiration warning, user is warned and link is offered for password-change form.

a.       If pw change link is used, then error-free completion would result in user redirect to service requested

3.       We appear to be constrained to using jsp views because there does not appear to be an option to add any additional objects to the request model, as sent to the view.  This was discussed in a prior thread a week ago, but for clarity we need to be able to leverage a dynamic html view template from our content management system.  We currently use jsp/jstl and a proprietary library to accomplish this nicely.

Some of this is obviously available, out of the box, but my questions are these:


1.        Is the IDP flow framework for the existing LDAP Password Authn extensible, such that we can introduce additional subflow(s) and flow-backing logic classes?

a.       If not, what strategy do you recommend, to achieve the requirements?

2.       Can there be any consideration in future iterations of IDP3 to allow for custom bean inclusion to the incoming request model for views?

a.       My idea(for whatever its worth) would be a designated spring beans xml file that lives in  /edit-webapp (like /edit-webapp/spring/add-model.xml) that would include an example-stubbed java.util.Map. The controller would include any map entries of during view model creation.  Then implementers can just add whatever beans they configure to the map and they would be available in the context at runtime.

Thanks so much for your time and efforts!  I know you guys get bombarded daily, and I truly appreciate you helping me out.

Josh O'Dowd
Software Systems Analyst / Developer
University of Montana, IT Central
(406)243-6283

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150724/c685a6eb/attachment-0001.html>