Provide ability to create a API-Key records in names.nsf for third party applications to connect to Domino resources for various reasons (Mostly REST-API, Web agents, DAS, etc.)
Right now customers provide a separate username password and the other parties use basic authentication. However this quickly escalates to a security nightmare after a point, especially when the company provides access for too many different parties. In addition, every user account with a static password is a security risk. Password management policies, e-mail routing and similar admin practices complicate management of these accounts further.
The idea is to create an alternative account type named API access.
- The credential may be formed in a long, random and complicated single string that is difficult to guess.
- Every API access account will have a separate name, so they can be referred in the Notes security model (ACL, reader/author, etc).
- API key will be valid only for specified URL patterns (that will also be automatically excluded from TOTP and Session authentication)
- API key would be defined for permanent access or it might expire after a limited time.
- Just like standard names.nsf documents, API keys should have Administrator user so they can generate new keys without admin involved.
I support this idea as well.
@Thomas, Although the OIDC Bearer token is a great technology, I don't think it ticks all the boxes for effective API key authentication. In the case of API keys, there is no need to federate the login process. API access accounts shouldn't require a user account, ID file, or admin involvement for their operation. The goal is to simplify secure, function-specific API-to-API access for Domino data.
I’m guessing if you put an OIDC provider connected with Domino that will work.
But it would be better if Domino could create these JWT tokens by it self using a notesid file in the id vault.
Would this OIDC Bearer token authentication that was introduced in V12.0.2 be the solution you were looking for ?
https://help.hcltechsw.com/domino/12.0.2/admin/secu_config_http_bearer_auth_using_oidc_c.html
I support this idea.
API keys appear to be the natural choice, when software components should consume Domino based services (machine-to-machine communication).
E.g. Volt Apps could become more attractive as machine-consumable services.
The alternative, x509 Client Certificates, are not working in situations when L7 Load Balancing has to be used.
Toni Feric