overridding admin interface beans/flows

[Bobby Lawrence]

Hopefully I'm missing something simple....
I renamed my flow to admin/customlockout and changed the shibboleth.AdminProfileId to something unique to our organization.
I can now access it via /idp/profile/admin/customlockout, but I cannot get the lockoutManagerId or the key for some reason.  Whenever I pass those in the path I get a 404 and see this in the logs:

WARN [org.springframework.web.servlet.PageNotFound:1278] - No mapping for GET /idp/profile/admin/customlockout/shibboleth.authn.Password.AccountLockoutManager

I cannot find what I seem to be missing.  Somehow SWF cannot route these REST requests properly.  I suppose I can change my custom DoLockoutManagerOperation to use query string parameters...

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Bobby Lawrence via users
Sent: Wednesday, December 14, 2022 9:42 AM
To: Shib Users <users at shibboleth.net>
Cc: Bobby Lawrence <robertl at jlab.org>
Subject: [EXTERNAL] RE: overridding admin interface beans/flows

Thanks Scott.
I will fully admit that what I did for this was unsupported but it was the only way to actually manage the in-memory lockouts.

To make it work I had to create my own in-memory lockout manager which provided a public method to return all the keys (mine only returned keys if the storage service was an instance of AbstractMapBackedStorageService).  I then created my own version of DoLockoutManagerOperation which would return all the keys when a special key ("all") was passed to it via GET.  All that was required to make it work was to create a custom admin/lockout flow referencing my own version of DoLockoutManagerOperation.

Sounds like my only option for this would be to create my own admin flow.  I guess I would somehow make it available at a different URL by creating a bean called shibboleth.FlowMap which is merged with shibboleth.DefaultFlowMap?



-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott via users
Sent: Tuesday, December 13, 2022 5:58 PM
To: Shib Users <users at shibboleth.net>
Cc: Cantor, Scott <cantor.2 at osu.edu>
Subject: [EXTERNAL] Re: overridding admin interface beans/flows

> 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://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_browse_IDP-2D2047&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bs2UfpzD0fSGcxiXJeDGwtg&m=9iwsypRglUX1EKXJ8OXVR6DAIgUdwF_k-MdG1VI2hLcmOJvZA18g2_uuwI_Mj6tW&s=uKe6ZYq2UfiuCD9ecRXniFh1nF0_XfUjdIsVEOJdW1I&e= 

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

--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_wiki_x_ZYEpPw&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bs2UfpzD0fSGcxiXJeDGwtg&m=9iwsypRglUX1EKXJ8OXVR6DAIgUdwF_k-MdG1VI2hLcmOJvZA18g2_uuwI_Mj6tW&s=bJ3rPDOO_5jkzuEwrEh6M_iMuMYT4xB5Y3KDiMcFi7s&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_wiki_x_ZYEpPw&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bs2UfpzD0fSGcxiXJeDGwtg&m=nwS0osZDQGn5OpnTq9wQwNJb9RgsZp7hsjsUkGf4na0S7ZpP3hvxc79ynIVnlMzE&s=fw2E5IyRVuvlfiFh4s3JIYtGlUKhZLbOfTSVHPcm4uo&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net