[GC] configuration picker dialog not being properly instantiated
I have implemented a configuration-enabled RM serviceprovider (SP). I have added an outbound friend in CLM 6.0.5's GC application to our SP. I open a GC stream, press 'Add Configuration', Configuration picker dialog opens up. I select my RM provider from the dropdown list. At this time, a single request to our Configuration Selection Dialog is sent without any credentials. I send back a 401 hence resulting in failure.
Expected behavior: In Jazz's QM/RM application, when I open a selection dialog to add a requirement from my SP, initially a request is sent to our serviceprovider service to get the selection dialog URI. In case, a 401 is returned in response to serviceprovider request, Jazz starts the 3 legged OAuth protocol. Resulting in login by a user from our SP and then the selection dialog opens with the credentials of the user who authorized the requestToken in 3 legged protocol.
Problem: Upon opening a GC stream in browser, Jazz sends a request to our configuration management (CM) service provider catalog as our SP is registered as outbound friend in GC. Then GC sends a request to our CM service provider and gets the configuration picker dialog URI. Both of these requests are sent with 2 legged OAuth signature, so we return the required data. But the request for configuration picker dialog doesn't bring any credentials resulting in a 401 from our side.
|
5 answers
Hi Saqib, let me restate that to make sure I understand you right.
1) You open GCM and there are requests made to your service provider, etc. documents to discover where your selection dialog is (URL to an HTML page). These requests are all done with 2-legged OAuth (i.e., the functional user) and succeed. That sounds right and expected. GCM may work with a large number of service providers at once, so it avoids prompting for user log in credentials at that point (other CLM apps don't have that concern so seem to prompt you with 3-legged OAuth, which is why they are behaving different for you). That sounds like it's working right for you, so your Friend setup sounds good.
2) In the GCM Add Configurations dialog, you then pick your service provider from the drop down list. GCM tries to show your your selection dialog (HTML page) by opening the dialog URL in an iframe on the GCM page. Your dialog expects to already be logged in at that point, but is not, so fails and returns a 401. The iframe shows an error or blank area depending on the web browser.
Do I have that right? If so, that is actually expected. The selection dialog URL is expected to handle its own authentication. It's just an iframe in the browser at that point, and the browser doesn't know how to handle OAuth directly. The CLM applications already do this: the request for the HTML dialogs doesn't require any authentication; the dialogs themselves prompt the user to log in on the fly if necessary.
Your dialog will need to do something similar to authenticate itself. The most obvious way is to redirect to a log in page (instead of fail with 401), then have that page redirect back to your selection dialog. The caveat there is that that is not how the CLM applications do it, so I don't know of a concrete working example of that. (Older OSLC-spec versions leveraged frame onload events for exchanging some info in older browser and that redirect could interfere with that--I don't think that's a problem any more but am not 100% sure).
I hope that helps.
|
Hi Saqib, did you add your provider as a friend to the JTS? I'm not an expert on the authentication implementation, but the sandbox environment I can access shows the GCM application referencing the JTS friend list, not friending the other CLM applications directly.
|
|
Thanks Kathryn for a quick reply but the problem is not resolved. As suggested by you, I have removed my ServiceProvider from GC's outbound friends list. I have added my serviceProvider as a friend in Jazz's JTS. But the behavior is exactly same as it was in the old configuration. Upon opening the GC Stream's page, it sends a request to my ServiceProvider's CM Catalog with 2 legged OAuth credentials. And I send back the catalog document. From there Jazz's GC gets the serviceProvider URI and sends a request to it with 2 legged OAuth credentials and my application sends back the serviceProvider RDF. From that Jazz gets the selectionDialog URI for OslcConfigurationPicker and sends a request to it without any credentials (3 legged or 2 legged OAuth) and my application is forced to send a 401 back.
I have tried opening selectionDialog thing with Jazz's DM, QM and RM too. In these three applications the behavior is different from GC application. In these applications (RM, QM & DM) before opening the selection dialog the application sends a request to our rmServiceProvider with proper 3 legged OAuth signature, in response to this request, either it gets the serviceProvider RDF or it gets a 401. If Jazz gets a 401, it restarts the complete 3 legged OAuth protocol that also involves login to our application to authorize the requestToken. Hence the subsequent request to the selection dialog is authorized due to the recent login to our application server.
|
|
Hi Jay, thanks for a detailed answer. You understood the problem correctly.
Now, I am showing a login page in the iframe if the user is unauthenticated. User logs in and the iframe redirects back to the selection dialog. User adds one of our streams in the GC stream. After several hours, if the user tries to open the GC stream page that contains a stream from our ServiceProvider, the GC application sends a request to our ServiceProvider to get the stream information with 3-legged OAuth. It then involves the login to our application. You have said in your answer that "These requests are all done with 2-legged OAuth (i.e., the functional user) and succeed... so it avoids prompting for user log in credentials at that point". But if our stream is present in the GC stream, it starts 3-legged OAuth and prompts for user to login. The behavior is somehow contradicting with your statement (correct me if i am wrong). Because of this 3-legged OAuth request to our ServiceProvider we are facing another issue.
In one of our other applications, we access CLM's GC application programmatically using form based authentication method. We get a global configuration that contains one of our streams then we try to create a GC baseline from the recently fetched GC stream. At that time during the creation of baseline, GC internally sends a request to our ServiceProvider to create a baseline from our stream. This request is sent to our ServiceProvider with 3-legged OAuth credentials. This request fails if we haven't already opened the GC stream in a browser window and not completed the 3-legged OAuth protocol. So the problem here is, we access jazz programmatically and jazz accesses our ServiceProvider programmatically but the involvement of 3-legged OAuth protocol (from jazz to our ServiceProvider) involves opening a browser to complete the OAuth protocol. A possible solution to this problem could be that the jazz sends baseline-creation request to our ServiceProvider using 2-legged OAuth credentials hence eliminating the need for a login window in browser.
Can you please shed some light on these issues?
|
|
Writing a non-interactive process like that can be challenging, and I'm afraid I don't have much experience doing that. There is quite a detailed write up on Jazz.net about writing a "native" client (i.e., not a browser). Hopefully that can help: |
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.