remove required permissions from /saml/regenerate endpoint

Just stumbled upon this ticket... Here's my take:

• move the configuration from mod-configuraiton to mod-login-saml - this means the module will now talk to a database and db connection parameters will need to be passed in like other storage modules.

  • this means that the module is "in the loop" whenever the saml configuration is changed, and it can react by regenerating the metadata automatically.

  • since making config changes requires permissions, there will always be a user context available for record metadata (createdBy/modifiedBy/etc.)

• remove the /saml/regenerate endpoint and introduce a new /saml/metadata endpoint that simply serves up the latest metadata - no need to check if something has changed and potentially re-generate the metadata.

FWIW the UI already calls mod-login-saml when configuration changes occur, and it's the module that calls out to mod-configuration. So these changes would be transparent to the UI, aside from maybe wanting to cleanup permissions - e.g. remove the regenerate permission from any permission sets defined in the UI.

How can we achieve this then? By adding an Edge API?

Per slack chat
Jakub Skoczen 3:04 PM
Thanks @hji, let’s hold on that ticket then. I also thought this is a trivial change but apparently not. Can you put this issue back to backlog and make it BLOCKED? And release 1.2.2 of mod-login-saml from master without this?

Hi @Theodor Tolstoy (One-Group.se) and @Jakub Skoczen, I thought this is a trivial change but when testing the change and looking at the code, I noticed when /saml/regenerate is called. It uses the x-okapi-token to make a mod-config call to update "metadata.invalidated" entry. Unfortunately, if we remove the permission protection, the call to mod-config failed because there is no user info in the call.
The way "metadata.invalidated" entry works is that it is created/modified with value "true" when user saves/modifies the configuration. When the /saml/regenerate is called, it changes the value from "true" to "false".
Is removing the permission protection a must? In general, more protection is a good thing. Otherwise, anyone can launch a load attack to the endpoints. It could stress the module and potentially other module or db if the endpoint triggers those calls like in this case.

It is to be considered safe to have this info public. For example, the Swedish federation Swamis publishes theirs online:
https://mds.swamid.se/md/swamid-idp.xml

The security is about public/secret keys and around the origin of requests. You can go ahead and remove the permissions for regeneration