Web flow allowing user to adapt SPNEGO login flow's behavior

[Schwoerer, Brad]

IMHO... It should be in a logical spot for the application (somewhat
buried to the end user) with a deployer using a local url
shortner/redirect to  get to the correct spot.



On 10/9/15, 9:58 AM, "dev on behalf of Daniel Lutz"
<dev-bounces at shibboleth.net on behalf of daniel.lutz at switch.ch> wrote:

>For the SPNEGO login flow, we want to allow the user to configure
>the auto-login behavior of the login flow. Auto-login is managed
>per client in a persistent cookie.
>
>As soon as the user enables auto-login, the user won't see any user
>interface in the future. Therefore, we need a way to allow the user to
>disable auto-login again. (A similar mechanism might be
>desired to allow the user to configure the "passthrough"
>behavior of the X509 login flow.)
>
>We think that such a configuration page for the user
>needs to be an integral part of the SPNEGO login flow.
>We think that a deployer should not be required
>to implement such a mechanism himself, e.g. by using
>JSP.
>
>I thought that implementing this as a web flow, similar
>to the "status" or the various "admin" flows, would be
>the best way to do it.
>
>I implemented a web flow that shows a page allowing the
>user to enable/disable the auto-login behavior.
>This web flow is called directly by the user. (It's not a subflow.)
>The flow manipulates the state of the SPNEGO auto-login
>cookie.
>
>I placed this flow at the following location (URL path):
>
>  /idp/profile/SPNEGO/UserConfig
>
>The Velocity template of the view that shows the page
>is located at the following filesystem path:
>
>  views/spnego-user-config.vm
>
>A deployer should be allowed to adapt the
>template to his needs. Therefore, it's located
>in "views" instead of "system/views".
>
>Are these locations suitable?
>Do you recommend other locations?
>
>Which are your general thoughts about such a
>"user config" page?
>
>I'm aware that there's the following issue:
>
>The user needs to now the exact URL of this configuration page.
>Therefore, it should be a well-defined location.
>The URL path /idp/profile might not be the best choice, but I
>couldn't find a better one. The "idp" servlet is bound to
>/status and /profile/* only.
>
>Do you see other options?
>
>- Daniel
>-- 
>To unsubscribe from this list send an email to
>dev-unsubscribe at shibboleth.net