How to use JEEFormAuthenticator to login to DWA for OSLC services

SDKs Lyo
1

Hello Everyone,
I’m very new to the OSLC specification and I started using OSLC4j version 4.0.0 to try to access the OSLC functionalities of RQM (QM) and DOORS (DWA). I’m using the JEEFormAuthenticator to validate the credentials against the context URLs. I have used the below code snippet to fetch the ‘ServiceProviderUrl’ and it seems to work fine for RQM(QM), but, getting 401 response code for a DOORS (DWA) . Could you please let me know what I could do to fix this?

But, using the same Discover URL in firefox seems to download a file name catalog with the required details.

// The code
private void connect() throws Exception {

ClientConfig clientConfig = new ClientConfig().connectorProvider(new ApacheConnectorProvider());
ClientBuilder clientBuilder = ClientBuilder.newBuilder();
clientBuilder.withConfig(clientConfig);
// Setup SSL support to ignore self-assigned SSL certificates
SSLContextBuilder sslContextBuilder = new SSLContextBuilder();
sslContextBuilder.loadTrustMaterial(TrustSelfSignedStrategy.INSTANCE);
clientBuilder.sslContext(sslContextBuilder.build());
clientBuilder.hostnameVerifier(NoopHostnameVerifier.INSTANCE);
// IBM jazz-apps use JEE Form based authentication
clientBuilder.register(new JEEFormAuthenticator("https: // servername: 8443/dwa/", "userName", "password"));
// https: // servername: 8443/qm/ for RQM
// STEP 2: Create a new OslcClient using the above configuration
OslcClient client = new OslcClient(clientBuilder);
RootServicesHelper rootServicesHelper =
    new RootServicesHelper("https: // servername: 8443/dwa/public/", OSLCConstants.OSLC_RM_V2, client);
// https: // servername: 8443/qm/ for RQM
// STEP 3: Get the URL of the OSLC ChangeManagement service from the rootservicesdocument
String catalogUrl = rootServicesHelper.getCatalogUrl();
// STEP 4: Find the OSLC Service Provider for the project area we want to work with
String serviceProviderUrl = client.lookupServiceProviderUrl(catalogUrl, "Project name");
//WARN org.eclipse.lyo.oslc4j.client.OslcClient - Cannot read https://servername:8443/dwa/rm   /discovery/catalog status: 401

}

2

I just learned the difference between the Authentication and Authorization. is it fair to assume that I have been successfully authenticated and not authorized to access that catalog resource?
So, I need to implement oAuth also to get access to the catalog?

3

Hi

If you got it working for RQM(QM), but not for DOORS, then it seems that your requests are valid. The problem is likely to be in the configuration of DOORS. Maybe you don’t have the authorisation to access this data in Doors?
Are RQM and DOORS of the same version/release?

Can you share where you got the code you share above from? this way we can see how updated it is.

Here a tip on under Lyo-samples a more recent piece of code where a client tries to communicate with an OSLC server. It might get you started on how to work with oAuth.
Try to see if that can be used to access both your servers

4

Thanks @jad for the reply, I’ll try out the oAuth sample in my use case and to work it out.

I referred to one of the oslc4j-client-sample codes for the test management at the below URL to create the above snippets.

5

One more thing Jad, my RQM Web URL is of format: https://serverName/qm/, while the DOORS DWA URL is of format: https://serverName:portNumber/dwa/oauth/oauth_login.jsp

can I assume that the oAuth is not required by the RQM server, while DOORS server requires it?

6

Hi

I am not too familar with the specific details of the IBM tool suite.
But the URLs you’re listing seem to be for the end user. You should find the ones relating to the OSLC REST API.
Something like https://servername/qm/rootservices, https://servername/qm/jazz/… or https://servername/qm/jazz/oslc/…

I’m sure the documentation of your specific version of the tools will tell you exactly what you expect. (My guess is that both support oauth. But that’s just a guess.)

, I think you should be looking for the OSLC REST
to be able to decipher the URLs, but something tells me these are not