It's all about the answers!

Ask a question

How do I change DCC resource from user/password to OAuth ?


Kevin Ramer (4.5k6171190) | asked Dec 13 '16, 4:44 p.m.
I asked about certain settings in teamserver.properties but it is yet unanswered.  So I thought I'd ask this in a different way.   In one DCC I setup there are 3 resources ( ignoring the warehouse ), two of which use and ID / password and the 3rd uses OAUTH.   Tracking down the OAuth token from DCC to the application I find it under Consumers in the related application.  

I would like to change the 2 other items to use OAuth, but I cannot find clear steps to do so or what I find leads to other questions.  i.e.

From DCC setup Resource Groups
OAuth-JTS
When you select OAuth-JTS as the authentication type, the Consumer key and Secret fields are displayed. In the Consumer key field, specify the consumer key obtained from the Jazz Team Server. And in the Secret field, specify the secret of the consumer key.
Many consumers are defined by setting up some application and the secret is never requested or exposed.  What then ?


2 answers



permanent link
Donald Nong (14.4k314) | answered Dec 14 '16, 4:35 a.m.
The secret should be from the application which the resource group is for.

Can you please clarify whether the application appears in the Registered Applications section or the Friends (Outbound) section in JTS?

If it's a Registered Application, I don't see any way to do it at all following the instructions, as the document says: "If the resource group is local to your Jazz Team Server where Data Collection Component is also registered, the Consumer key and Secret fields are automatically complete with the values configured when the application was registered and finalized during the Jazz Team Server setup", and of course the secret has never been exposed. Maybe you need to unregister DCC and register it again in this case?

If it's a Friend, you should be able to change the secret in the configuration - Friends (Outbound) section in JTS and consumer section in the other application.

Comments
Kevin Ramer commented Dec 14 '16, 1:14 p.m.

In the DCC OAUTH key of the resource corresponds to the same application under JTS Registered Applications.   I'm reluctant to re-register as I've seen it recommended to not do so.



Kevin Ramer commented Dec 14 '16, 2:10 p.m.

More from the docs:

OAuth-JTS
When you select OAuth-JTS as the authentication type, the Consumer key and Secret fields are displayed. In the Consumer key field, specify the consumer key obtained from the Jazz Team Server. And in the Secret field, specify the secret of the consumer key.
Tip: If the resource group is local to your Jazz Team Server where Data Collection Component is also registered, the Consumer key and Secret fields are automatically complete with the values configured when the application was registered and finalized during the Jazz Team Server setup.
So:  What happens if I were to redo the discover ? [ I don't recall how these 2 came to be using ID / password ]


Donald Nong commented Dec 14 '16, 7:26 p.m.

I would think it's quite safe to re-register DCC but I'm not maintaining a production system so don't feel the burden. To re-do the discovery, you need to remove the existing resource group first, which is something you will be reluctant to do as well, if I understand correctly. Also, the discovery feature does not auto-fill the key/secret for you, so it's no better than what you have now. It appears that the auto-completion only happens when you "register" DCC, based on the "tip" that we both quoted.


permanent link
June Boston (1941737) | answered Dec 14 '16, 2:58 p.m.
 If you want, you can manually create OAuth keys.  Create an OAuth key/secret combo, set it as Trusted and set the functional user as etl_user (who should be assigned all the data collection licenses).  You can now just manually use that key/secret combo in DCC to have it run as OAuth.

While DCC 6 technically should do this for you, I've found in some upgrades it doesn't do so, and manually creating OAuth entries in each application and then in DCC's Resource Group Config is faster than deeper troubleshooting attempts.

Comments
Kevin Ramer commented Dec 14 '16, 3:04 p.m.

Seems reasonable.  Does the creation of the new oauth happen on the DCC or the target app ?


June Boston commented Dec 14 '16, 5:18 p.m.

 It must happen on each target app, so basically all these pages:

jazzserver/jts/admin#action=com.ibm.team.repository.admin.configureOAuth
jazzserver/ccm/admin#action=com.ibm.team.repository.admin.configureOAuth
jazzserver/qm/admin#action=com.ibm.team.repository.admin.configureOAuth
jazzserver/rm/admin#action=com.ibm.team.repository.admin.configureOAuth



Donald Nong commented Dec 14 '16, 7:21 p.m.

I actually tried to do this before I posted my answer, but gave it up. Basically, you cannot add a second OAuth key for the same application. It's my understanding that for registered applications, the only way to change OAuth key is to re-register them, but it does not solve the problem that we never get to know the OAuth secret. That is the reason I suggested re-registering DCC instead. Also, at first I thought the OAuth key would be between DCC and the applications, but it turned out to be more complicated. Based on my observation on the automatically created resource groups, the OAuth-JTS key refers to the key with which JTS is registered as a friend to the other applications. In other words, DCC uses JTS as a "proxy" to visit other applications. I don't have any documents to back up my theory, and it's purely based on observation.


Kevin Ramer commented Dec 15 '16, 8:38 a.m.

The real problem I'm trying to solve relates to entries in DCC resource groups.  What are the ramifications of dropping the 2 using id/password and recreating ( hopefully to use OAuth ) ?


June Boston commented Dec 15 '16, 5:55 p.m.

 You can add as many OAuth keys as you want, you do not have to specify the application.  The "functional user" is the user it emulates when the OAuth key is used, which is why we pick the system-level etl_user to perform ETL jobs.  Each application automatically generates one or more OAuth keys, true, but you can't get those secrets and they are bound to the functional users (ie ccm_user, dcc_user).  That's just part of the apps communicating with each other.


If you make a new OAuth key you can use it in the DCC Resource Group config.  It is NOT the same as the dcc_user OAuth entry that is put into the JTS OAuth keys list during setup. Leave those auto-generated keys alone.  The "Register Consumer" section on the Consumers (Inbound) section of each app's admin panel is where you set this up; after creating it, you find it in the list on this page to assign the user.

You can create your own OAuth keys for use with DCC, as well as for things like Rational Publishing Engine and other non-CLM applications that must authenticate with CLM.


June Boston commented Dec 15 '16, 6:02 p.m. | edited Dec 15 '16, 6:04 p.m.

 So to clarify, you go make a new trusted OAuth key/secret in each CLM app admin panel, find the key you just created in the list on that same page, edit it to use etl_user as the functional user, then go to DCC's Resource Group Config page and replace your username/passwords with the OAuth key/secret (and change the Authentication type to OAuth - JTS).  Find etl_user in your JTS user list and make sure etl_user is assigned the various data collector licenses.


It is completely unrelated to the dcc_user OAuth entry that is generated on registration of DCC with a JTS server.


Donald Nong commented Dec 15 '16, 7:23 p.m.

So this is just the basic OAuth stuff. I wonder why they named it "OAuth-JTS". If DCC can communicate with other applications using OAuth, without the need of JTS, the authentication type should just be called "OAuth".

showing 5 of 7 show 2 more comments

Your answer


Register or to post your answer.