Create a document builder connection to DNG via OAuth Consumer Key/Secret
In the document builder (V7.02 SR1) i want to setup a connection to a Doors Next module / view for building a report.
I don't want to use an user account to authenticate the connection, therefore i was looking for an alternative way. I tried creating an OAuth Consumer under the JTS and RM administration but it failed.
What is the best way authenticate the connection
One answer
Hi Michael
You should use a user account because that's the basis for read access by the user being a member of a project.
If you're using JAS you might be able to create an application password but I'd still expect that user to have to be made a member of the project. And I don't know how to get PUB to authenticate using an application password.
Application passwords are managed by JAS with OIDC - indeed they're a way to be able to get controlled access separately from LDAP/AD - the application password can be expired/removed when you want to block access using it. TBH I've never used one but it seems they are an additional password on your user id: "Use the application password in place of your regular account password in the clients that you use" - that sounds good because then you don't have to also administer a new functional user dedicated to reporting: just use your own user id.
Iinfo on application passwords is here https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/lifecycle-management/7.0.3?topic=installation-application-passwords-native-client-authentication-openid-connect
I don't know how to configure a report to use application passwords, or even if it's possible.
I strongly suggest you don't attempt to use one of the existing functional users for reporting - your challenge with automated password expiry turns into the opposite problem that the functional user can't possibly be revoked/disabled.
UPDATE 8th Nov - having done some work with OAuth1 credentials: these still expire, default is 6h - this is configurable but it's difficult to imagine any corporate security organisation agreeing to a user having insecure (because of an elongated expiry time) credentials.. And anyway you need the functional user id and password to generate new OAuth1 credentials so you are also still subject to password expiry on the functional ID.
HTH
Ian
Comments
I was assuming that assigning the "Functional User ID" of the OAuth Consumer to a real user account with access rights to the project is intended for this purpose?
How would the JAS approach look like? We use an active directory for user management, with some restrictions and rules e.g. periodic password changes. Which makes it hard to use such an account for periodic reporting
I updated my answer
I updated my answer again with more details of why OAuth1 credentials won't help you avoid password changes