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

[Cantor, Scott]

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



>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.

Yeah, we've been putting this off basically. There are a few things like this we need to have, like consent management, so one of the problems is the "first mover" issue, avoiding doing this so we don't have to decide a bunch of "first time" things that we'll get stuck with when we haven't thought about it yet.

I almost did a page like this recently for revoking consent, but I put it off.

>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.)

Yes, I understand (of course, some of them might be usable as subflows also, to allow them to be used mid-request).

>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

Using the views directory for any templates is fine (understanding that once we do it, we're committed to it).

>Do you recommend other locations?

Not for the view. I need to think about the location question, it's just been put off over and over.

Tentatively I'm thinking maybe we use /idp/profile/user for "user-admin" flows.

>Which are your general thoughts about such a "user config" page?

Well, one thing is I'm not sure if we want separate flows or one flow with multiple features we can build on. But the more we try and predict, the harder it is to get right.

Also, I had thought we probably wanted an API that would allow this to be done without user intervention so that other components could build links that would perform specific actions silently, which would obviously need to reuse portions of this kind of flow.

>The user needs to now the exact URL of this configuration page.
>Therefore, it should be a well-defined location.

For our purposes, yes. Bradley's right that a well-managed deployment would abstract that away into some other portal or mechanism they can control, but we can't design around well-managed deployments.

>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.

The reason for that is that the way we're using webflow, every flow is visible to any place the idp servlet is bound. I left /status bound because of compatibility but without the wildcard. And we don't want to have to modify web.xml to add flows (obviously), so that means using a wildcard and if we add another one, you could run any of the profiles that way (which isn't exactly unsafe, but has the potential to open holes if something goes wrong).

I guess what we have to do is just suck it up for now, try and create a reasonable starting convention and then just accept that it probably will end up deprecated and maintained for compatibility in the future.

-- Scott