Customizing Login & Workflow

Joel Levin joel.aaron.levin at
Wed May 11 20:03:03 EDT 2016

Thank you for the replies!

Re-summarizing below -- would you be able to validate if I am on the
correct path

For Login page customization:

1) Run './' to build the IdP on a local server's file system
2) Place '/opt/shibboleth-idp/views/' in subversion or Git -- for local UX
team to update
3)I will the figure a way to deploy this to the IdP servers (independent of
the './' or './')

For the login work flow change - to check if password update/ToU agreement
required -- we unfortunately have a very custom database driven mechanism
-- and require to produce pages which redirect to a separate application
(users has up to 5 chances) -- can you recommend a working code to emulate?


On Tue, May 10, 2016 at 12:43 PM, Nate Klingenstein <ndk at> wrote:

> Joel,
> > Next step: we will customize the login page,
> Login page customization details are available as part of the InCommon
> Shibboleth workshop series:
> >  and implement a workflow for Terms of use agreement & password change.
> You’ll find tons of stubs or working code for this if you’re using the
> standard flows.  You may not need to do anything other than wire up the
> standard flows to the right checks.  Depends on your use cases, I think.
> > Is above a suitable best practices path?
> The developers are very clear about which interfaces are public and which
> interfaces are private.  I would stick to intended extension points
> whenever possible.  A class you customize is a class you maintain.
> Take care,
> Nate.
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list