|
I think I have now a better picture of what you are trying to achieve. Let's see if we can achieve the module split you are suggesting.
1) oslc4j-core
2) oslc4j-jena-provider
3) jsr311-api
So, if we try to rename that module into client-wink, we will have to still depend on these modules. If we keep the first two deps pinned at 2.4.0, I see little reason not to tell people to stick to the old Client. If we do the upgrade to 4.0,
then there will be problems with Jersey from oslc4j-jena-provider dependency:
So, I think this brings us back to drawing board.
/Andrew
Jad,
I think you have this exactly right.
1. client-core would depends only on JAX-RS 2.0 and oslc-core
2. client-wink would be what we have now, unchanged
3. OSLC client applications that use client-core would provide whatever implementation of JAX-RS 2.0 they want, and configure it how they want
4. we will have two versions of the sample client applications, one that is unchanged and uses client-wink, and another that uses client-core and provide examples on how to use Jersey to create runnable
code.
Any wink/jersey based client can work with any wink/jersey based server.
No client or server would need to support both wink and jersey
Do we all agree?
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad El-Khoury <jad@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 01/24/2019 06:30 PM
Subject: Re: [lyo-dev] Migrating lyo.client from Wink to Jersey
Sent by: lyo-dev-bounces@xxxxxxxxxxx
I believe the aim is to migrate OSLC4J from JAX-RS 1.1 to 2.0 (and not necessarily from Wink to Jersey). But we also wanted
to remove the dependency on Wink, to allow developers using Lyo to adopt other JAX_RS implementations.
There was a particular desire to make “the client library dependencies were much smaller and simpler - today with Wink et
al they are huge” – as formulated by Nick Crossley.
So, we should not be adding a dependency on Jersey, right?
I have not earlier used OslcOAuthClient nor JazzFormAuthClient, so I did not fully grasp all the details in your summary.
My general understanding from your text is that (1) they are not up to date with oslc 3.0 (2) they are far from perfect.
As a small step that allows us to move away from Jax-rs 1.1, while maintaining Wink support, does it make sense to split the
current client code into 2 projects:
1. client-core that offers the CRUD and lookup functionalities, but without having to deal with client (or clientConfig) constructors.
2. Client-Wink that offers the capabilities of creating clients for OslcOAuthClient, JazzFormAuthClient & OslcClient
The former is NOT dependent on Wink, but on Jax-rs2.0 only. The latter is dependent on Wink.
In future steps, we can then improve the 2nd to support clients for OpenIDConnect (for example). But we
can also provide a Client-Jersey alternative.
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
There are technical, security and maintainability benefits for migration OSLC4J from Wink to Jersey. I won't discuss the motivation here. Rather
I want to explore possible design strategies and API and implementation implications. For lyo.client, this will be a significant API breaking change that may push responsibility for certain HTTP communication configuration up into the client applications.
Although these changes will improve security, OSLC4J users may be challenged to migrate their existing client applications to 4.0.0, especially if other parts of their technical architecture have related/coupled technical debt that they are not prepared to
address. So we should make this change carefully.
Ideally OSLC4J 4.0.0 lyo.client would support Wink or Jersey, allowing users to migrate as needed in their applications. This not explores how the current OslcClient, its subclasses, and client applications work, and how this might change when migrating to
Jersey.
There are currently three OslcClient variants:
OslcClient: provides generic CRUD method for OSLC resource access supporting SSL with configurable trust managers, with a default trust manager that trusts all client/server interactions over https. This capability is often used during development and testing.
JazzFormAuthClient: Extends OslcClient to support Java EE Form based authentication as used by the
jazz.net apps. OSLC client applications typically use JazzRootServicesHelper to read the
jazz.net app rootservices document, and provide the URLs to the services' ServiceProviderCatalogs.
OslcOAuthClient: extends OslcClient to support OAuth authentication as used by the DOORS Web Client.
This perhaps identifies our first design issue. A lot has changed in authorization since lyo.client was originally developed. The
jazz.net apps now provide lots of ways to authentication including OpenIDConnect. Also other OSLC servers like the iotp-adaptor on the Watson IoT Platform use HTTP Basic authentication of SSL and this is not directly supported,
requiring an interceptor in order to add the authentication header.
Ideally lyo.client would at least support the two authentication mechanisms recommended by OSLC Core 3.0: Basic and OpenIDConnect, neither of which are supported now.
But ignoring that, let's look at how these current OslcClient variants work and what would be required to migrate them to Jersey.
Simple OSLC client applications
The simplest OSLC client applications that don't need SSL and don't require login. GenericRMSample is an example of such a client application.
These client applications can use the default OslcClient() constructor. This default constructor supports http and automatically trusts all client/server communications with all hosts over https. Alternatively client applications can use the OslcClient(TrustManager[],
X509HostnameVerifier) constructor to specify more specific and secure communications over SSL.
OslcClient supports:
- create, get, update and delete resource
- Lookup the ServiceProvider URL given a ServiceProviderCatalog URL and ServiceProvider title
- Lookup the query capability URL given a ServiceProvider URL
- Lookup the creation factory URL given the ServiceProvider URL and possibly the OSLC domain, resource type and OSLC usage
Here's a brief summary of the OslcClient(TrustManager[], X509HostnameVerifier) constructor:
Creates a TheadSaveClientConnManager DefaultHttpClient
- Turns off redirects.
- unregisters https from the SchemeRegistry of the httpClient
- Creates a TrustManager[] that has an X509TrustManager that ignores checkClientTrusted and checkServerTrusted calls in order to trust all certificates - a security issue!!
- uses this TrustManager[] if the one provided in the OslcClient constructor was null
- uses SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER if the one provided by the OslcClient constructor is null. Also a security issue!!
- Creates an sslContext from a list of secure socket protocols: TLSv1.2, TLS, SSL, SSL_TLS
- initializes the sslContext with the trust managers
- re-registers a new https Scheme in the SchemeRegistry with an SSLSocketFactory that uses the SSL context and host name verifier created above
- Creates a javax.ws.rs.core.Application and adds the JenaProvidersRegistry and Json4JProvidersRegistry providers.
- configures the clientConfig with the applications
- uses this clientConfig to the Wink RestClient used to access all resources
There are a couple of additional methods in OslcClient that are only used by the OAuth clients. These will be discussed below.
jazz.net OSLC client applications
In the early days, all the jazz.net applications used JEE Form based authentication. lyo.client provides JazzFormAuthClient as an extension to OslcClient to handle the Form based authentication. However, client applications
generally don't use JazzFormAuthClient directly, they instead use it indirectly through JazzRootServicesHelper. RTCFormSample is an example of such a client application.
JazzRootServicesHelper:
- Constructor figures out the namespace and service providers property to use to identify the ServiceProviderCatalog URLs in the
jazz.net app rootservices document
- uses new OslcClient() to read the root services document when it is constructed with JazzRootServicesHelper (String url, String catalogDomain). Authentication isn't required to
read this document.
- Then the client application calls helper.initFormClient(userid, password) which constructs a JazzFormAuthClient from the helper's baseUrl, and the userid, password.
- The client application then calls client.login() to actually login using Jazz Form based authentication.
- the client application can now use the JazzFormAuthClient subclass methods to do OSLC CRUD operations on
jazz.net app resources, and use the service discovery method of an OslcClient
-
This immediately raises the issue that the JazzRootServicesHelper, and JazzFormAuthClient do not provide any means for the OSLC client application to specify trust managers or host name validators, all
SSL client/server interaction to any server is unchecked! SSL is essentially ignored.
So I'm not sure this could be used in a potentially insecure production environment.
OAuth OSLC client applications
Since DOORS Web Access required OAuth, lyo.client needed to provide OslcOAuthClient to extend OslcClient to provide OAuth 1.0a authentication (which was in common use at the time). DoorsOauthSample is an example of such a client application.
OSLC client applications that use OAuth also use JazzRootServicesHelper to not only get the ServiceProviderCatalog URLs, but also the various OAuth URLs including:
<jfs:oauthDomain>https://ce4iot.rtp.raleigh.ibm.com:9443/iotp</jfs:oauthDomain>
<jfs:oauthRequestConsumerKeyUrl rdf:resource="https://host:9443/iotp/services/oauth/requestKey"
/>
<jfs:oauthApprovalModuleUrl rdf:resource="https://host:9443/iotp/services/oauth/approveKey"
/>
<jfs:oauthRequestTokenUrl rdf:resource="https://host:9443/iotp/services/oauth/requestToken"/>
<jfs:oauthUserAuthorizationUrl rdf:resource="https://host:9443/iotp/services/oauth/authorize"
/>
<jfs:oauthAccessTokenUrl rdf:resource="https://host:9443/iotp/services/oauth/accessToken"/>
The OSLC client app then uses the helper.initOAuthClient with the consumer key and secret to construct an OslcOAuthClient instance that also has the OAuth URLs obtained from the rootservices document.
The OSLC client application then attempts to get a protected resource, catches any OAuthRedirectException, and then calls its validateTokens method to do the OAuth 1.0a dance, given the user id and password (there is no browser popup involved to access the
user's credentials).
This raises the same issue as JazzFormAuthClient. All the OslcOAuthClient constructors also use the default OslcClient() constructor which again trusts all client/server communications from all hosts over SSL. In addition, a client application that uses parameters
for user ids and passwords this way is achieving no additional security over HTTP Basic while incurring the additional complexity and overhead of OAuth and its variants. This is because there's no independent step between the client and the server where the
user gets a chance to decide if they want to provide their credentials in response to an authentication challenge - the client app just does it.
Potential conclusion
With this analysis, it appears lyo.client doesn't support the recommended OSLC Core 3.0 approaches to authentication, and interacts apps requiring JEE Form based or OAuth authentication without any SSL protections.
I'm inclined to see if there's a way to leave the current lyo.client Java client API on Wink and create a completely new client API and sample apps using Jersey that does support SSL, Basic and OpenIDConnect properly, while being sufficiently open with the
client configuration to support whatever the client application needs.
Thoughts?
Sorry for the long note. But this wasn't documented that I know of, and I couldn't reason about the situation without writing down what's there.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
|
