access to Doors NG through REST API, is oAuth required?
I'm trying to access the OSLC REST API's for Doors NG 5.0.2. All I want to do is simple integration, I want my application to talk to Doors NG through their REST API. There is no delegation needed (it's 1 to 1) so I have no need for the oAuth dance and would really prefer not to do it. I've been working under the assumption that I have to use oAuth whether I want to or not (or whether it makes sense). However every once in awhile I come across some documentation that suggest Form or Basic Auth can be used and that I can sidestep the oAuth completely. I've also seen some documentation that suggests that two-legged oAuth is a possibility if you have Consumer Keys/Secrets registered (which I do). Does anyone know whether any of the above options are viable? And can point me towards examples of using them? All I see are hints and when I try it doesn't work.
|
4 answers
Good morning Allen.
I know that it's been a long time from your contribution to this blog but, do you remember how you managed to communicate with the DoorsNG API?
Thanks in advance.
Comments The starting point for access to OSLC APIs is here - it's old so you won't see the exact URLs in the article but the approach still works - if you have questions about this create a new question don't use this question. https://jazz.net/library/article/1197 |
|
Thanks for the clarification on the two API's, you had me scared there that I was going down the wrong path :-) I can completely understand why you'd think OAuth is usually used between two applications, but when you're not delegating authority to another party then it doesn't make much sense to use OAuth. I've figured out how to do the OAuth approach using soapUI and the OAuth spec (took me a long time and a lot of guesses) and it takes a total of 8 REST calls (without using redirects) before I have the final token and can make that "real" OSLC API call. By using that java workshop I was able to take a few calls off (down to 6) but it makes no sense to me as it doesn't seem to follow the OAuth spec at all, heavily uses cookies throughout, doesn't use the consumer key/secret at all, starts out with a failed API call (to get cookies). I would feel much more comfortable with it if it was more than just a code example. I see you're going with some kind of OAuth 2.0 derivative in DNG 6+, maybe that will make it all easier. But I was really hoping for a solution that would just allow a simple authentication between the two apps. But I'm guessing that's not an option :-) |
I believe you are talking about the OSLC API, not the reportable REST API. In this case, OAuth is not required, and you can do a form-based authentication. Take a look at the Lyo project, it has almost everything you need.
http://www.eclipse.org/lyo/ This article should be a good starting point. https://jazz.net/library/article/1382 For a good explanation of the RM OSLC API, see this article. https://jazz.net/library/article/1197 Comments thanks for the response, but that definitely confused me. What's the difference between the OSLC API and the "reportable REST API"? I want to talk to Doors NG, I thought I had no choice but the OSLC API and I thought it required OAuth. I pretty much stayed away from Lyo as I'm not doing Java development and I didn't want a dependency on an Eclipse project. But I thought it was using OAuth, I'll take a look at it. I've seen both those links but I'll take a closer look at the 1st one since it refers to Lyo. the 2nd link ends up referring to the workshop which does use OAuth (and Java). My eyes must have played tricks - I thought you were using Java. Sorry about that. But you should be able to work out the workflow anyway.
|
Maybe you have already seen this, but the open REST service API to interact with DNG is the Open Services for Lifecycle Collaboration: OSCL web site.
For me the best way to see how see hands-on with code how things work with OSLC is the workshop which you can access with this article. There you also can see the code to do form based auth with DNG. Note also the Eclipse Lyo project to get you going with OSLC. And let me see if I can put this correctly: yes, you use OAuth the authenticate/authorize access to DNG. To provide your user/pw though, you can use basic or form based, but think DNG only accepts form, though I never tried basic auth to see if it works. But you still go through OAuth authentication. Regarding consumer key and secret, you can establish a friend relationship with DNG to associate projects between your app and DNG, but still means you need to be authenticated to perform actions against DNG. Comments Thanks for the reply! I've spent tons of time looking over the OLSC web site (OLSC does not require oAuth by the way, they say Basic Auth is fine). OSLC doesn't really help you with Authentication, that seems to be left up the vendor (IBM). I've looked at that workshop and the Java classes in it. I'm not using Java so that's one negative. But the big negative is the example seems to completely rely on Cookies and doesn't even seem to be following the oAuth spec at all or using the URL's for oAuth that Jazz/jts provides. It's more confusing than helpful unless you were using Java and just wanted to cut and paste I guess. The oAuth spec is pretty easy to follow, but it leaves the 2nd leg pretty wide open to vendor interpretation (where the resource owner has to authorize) and that's the part I'm having trouble with. As far as Basic Auth or form based Auth I was hoping there was a way to do that without using oAuth at all (I know it's needed as part of the oAuth dance). Like I said before I don't need the whole delegation thing at all. But looks like what you're saying is Basic Auth alone is not an option (which is sad). I was hoping the consumer key and secret would at least let me do 2 legged oAuth (without the delegation aspects). I see some suggestions of this. I found in IBM documentation something about a "shortcut for Authentication using consumer key/secrets" and was hoping this was at least 2 legged oAuth. So long story short, it sounds like you're saying full 3 legged oAuth is the only option? If that's true, do you at least have some kind of example that uses your own provided urls from your own /rm/rootservices that actually follows the oAuth spec? The 3 urls are: /jts/oauth-request-token /jts/oauth-authorize (form authentication/delegation happens after this) /jts/oauth-access-token
Thanks again!!
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.