Potential use-cases could be when there are organisations who want to disable API-based access using external auth integrations like LDAP, SAML or OAuth2. In such setups, sometimes when a user leaves the org - admins would block the auth from the external system (LDAP/SAML etc.) but they may continue to use API/secret-key based access. Granular control would also allow admins to implement their org-specific control and needs.
Regards. ________________________________ From: Abhisar Sinha <abhisar.si...@shapeblue.com> Sent: Wednesday, September 25, 2024 14:17 To: us...@cloudstack.apache.org <us...@cloudstack.apache.org>; dev@cloudstack.apache.org <dev@cloudstack.apache.org> Subject: Re: [Proposal] Disable API (apikey/secret-key) for users, accounts and domains That's right. This will be useful for cases where 3rd Party authentication mechanisms are used instead of username-password based. Thanks, Abhisar ________________________________ From: Nux <n...@li.nux.ro> Sent: Wednesday, September 25, 2024 5:02 AM To: us...@cloudstack.apache.org <us...@cloudstack.apache.org> Cc: dev@cloudstack.apache.org <dev@cloudstack.apache.org> Subject: Re: [Proposal] Disable API (apikey/secret-key) for users, accounts and domains Hi, Seems like a nice idea, but one can still access the API with the user and password right? So what exactly are we achieving? On 2024-09-24 09:03, Abhisar Sinha wrote: > Hi All, > > I am working on this feature where Root Admin will get the option to > disable Api key/ Secret key based access for a User, Account, or a > Domain. > Api keys are primarily used for automation. It is the primary > authorization mechanism used by automation when password-based access > is not used. > This feature will be useful for Root Admins who may want to block > certain users/accounts from using them. Or the Admin may want to > disable Api key access for the whole domain and allow only for certain > users. > > I've created a spec here : > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=323488155 > Your comments and suggestions are greatly appreciated. > > Thanks, > Abhisar
