Hi,
I have a hundred ACLs on my integration server, and I would like to allow the anonymous group to each of these ACLs, but doing it manually via the security IHM is painful, is there a way to do it in bulk via a webMethods service or a command?
Thanks
@Yassine_Dayski crude way is to use WmRoot service
wm.server.access:getACL
wm.server.access:updateACL
Safe way is to write Java service using ACLManager class if you run in sensitive environments
Hi @Senthilkumar_G , thank you for your response.
Could you please tell me where can I find these services to invoke theme ? because I can’t find the WmRoot package on my designer even if it is active in managment IHM.
Regards
Be aware that WmRoot components are not intended for direct use by us users. If anything goes wrong and you need support, support will not be able to help.
Edit: watt.server.ns.hideWmRoot in extended settings can be changed to true so that the package is visible in Designer. But as noted, this is not intended for us to use. There is no documentation for the inputs/outputs so you’ll need proceed with caution.
I don’t see this in the javadocs for the IS API. Is this something that may also be a “vendor use only” item?
Another option to consider is the IS Administrator API. It has these operations:
GET /admin/acl/ Retrieves all access control lists.
POST /admin/acl/ Creates an access control list.
PATCH /admin/acl/{name} Updates an access control list.
PUT /admin/acl/{name} Replaces an access control list.
DELETE /admin/acl/{name} Deletes an access control list.
The IS Administrator’s Guide has info.
Edit: As an aside, 100 ACLs seems extreme. Adding Anonymous to them also seems extreme. It may be appropriate to revisit the scheme being used.
If they are all in same folder(in same package as well), you can set them from the parent directory using designer.
If they are not, creating an anonymous package and implementing wrapper services in that package should be considered. Personally, I wouldn’t want anonymous ACLs to be distributed around the packages. Keeping them in one place will make monitoring/configuration easier.
Refer to the IS Admin API.
@reamon Correct. This is also internal class.
IS Admin API is the public option as @wayne.leishman.20059 said
In the “old days” of wM (pre 10.7 anyway) the WmRoot services were occasionally used to build custom services to automate activities normally done in the IS admin UI.
I believe it was 10.7 when @michael6 from Software AG created the IS admin API. The IS admin guide covers the capabilities and there are sample Postman collections of using the API somewhere in the tech community.
When the admin API came out I added some info on it into the wM integration admin course (back in the days when i was a webMethods instructor for Software AG).
The info i used came from Michael and the IS admin guide.
@reamon thank you for your response.
In our company, we have around ten teams, each team calls many services represented by packages on IS.
There are services that are common between one or more teams.
For the moment the calls are anonymous, but we are thinking of securing them, so we thought of setting up ACLs.
package = service_v1 = service_v1 ACL
and each acl we will authorize one or more groups (teams).
Do you have another solution to offer me please?
Thanks and regards
In our company, we have around ten teams, each team calls many services represented by packages on IS.
There are services that are common between one or more teams.
For the moment the calls are anonymous, but we are thinking of securing them, so we thought of setting up ACLs.
package = service_v1 = service_v1 ACL
and each acl we will authorize one or more groups (teams).
Do you have another solution to offer me please?
Thanks and regards
Thanks for the additional info.
Others will share their views on this, but for me you’re going from one extreme to the other – anonymous access to 100s of ACLs. You likely can devise a scheme that strikes a balance between securing access but not creating too much administrative overhead.
IMO, do not create an ACL for every service. That’s likely more granular than necessary. You might consider grouping services into logical groups. And group the applications/teams (whichever makes more sense). We organize around applications (apps that call or are called) not teams but organizing by team may make more sense in your case.
Define an ACL for each service grouping, not each service. Keep the number to the smallest possible/logical. Add the apps/teams user accounts/groups (prefer groups over individuals) to the memberships as needed.
Another way to think of it, which may apply to your environment – imagine if you didn’t have wM components as an intermediary and instead applications interacted directly with each other. You’d have permissions focused on those applications, not really on each component within those applications.
HTH.
This part is not clear to me. Do each team have their own package they can call? If thats the case set the ACLs on package level, and then you can add a wrapper service to each teams own package so that you don’t have to manage ACLs on service level. If you try to set that many ACLs one by one, it will be a maintenance nightmare.
Like Rob, I also prefer setting ACLs on application level unless a package owner is a different team.