Customizing Login & Workflow
joel.aaron.levin at gmail.com
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
For Login page customization:
1) Run './install.sh' 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 './install.sh' or './build.sh')
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 sudonym.me> wrote:
> > Next step: we will customize the login page,
> Login page customization details are available as part of the InCommon
> Shibboleth workshop series:
> 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,
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users