overridding admin interface beans/flows

[Cantor, Scott]

> We use the in-memory account lockout feature but found that the admin
> REST interface to manage lockouts doesn’t provide enough in its GET
> output.

i.e. https://shibboleth.atlassian.net/browse/IDP-2047

> We wanted to have the ability to list all of the current lockouts so that we
> didn’t need to know the exact lockout key.

AFAIK that's impractical short of reimplementing the whole thing; I don't know how you could have managed it. I would certainly be curious, perhaps I'm overlooking something...

My plan was to basically redo the feature in V5 to allow for it, which means changing the storage model.

> So I created my own “DoLockoutManagerOperation” bean and injected
> into the IdP via an extension. I believe that order to make it work, I had to
> effectively copy the entire admin/lockout flow XML files into my jar file
> because simply creating another DoLockoutManagerOperation bean in
> my postconfig.xml orclasspath:/net/shibboleth/idp/flows/admin/lockout->beans.xml or even in global.xml wasn’t enough. 

Copying anything in system/ has always been off limits. Whether it's the only way to make it work isn't the point, it's just not supported.

> Is there not any way to override the admin flows in 4.x? How can I
> override the “DoLockoutManagerOperation” bean and inject in my own
> version that provides more JSON? 

There wasn't any way in 3.x, what you did wasn't supported. There are some undocumented ways to override or block the built-in flow IDs, but with something like this, I would simply use my own flow ID by adjusting the flow filenames (and those files go in the user-defined flows folder, they don't go in the now-empty system directory).

There is no way to "just replace" one internal bean or extend it. When we allow for flows to be customized, that's done through specific extension points that never involve just copying things. Essentially you forked the IdP, rather than extending it.

The other problem is that any copying of our flows will reference implementation classes. Allowing that people do it, you would have to recognize that stuff will break at times, even in patches. So it's not a good idea.

So the short answer is, what you're doing isn't supported, but if you copied stuff and created your own flow under a different auto-generated ID by sticking the files in the flows folder, that can work (*), it just won't necessarily keep working across upgrades. So I wouldn't do it, but it's physically possible.

-- Scott

(*) Adding admin flows (or login flows, or interceptors) also requires creating a particular flow descriptor bean that auto-registers itself, that's a 4.1 change to make plugins easier. That part is fully supported and documented (poorly) in the developer side of the wiki.