[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [lyo-dev] Migrating lyo.client from Wink to Jersey
|
Jim,I think your description of how to handle
the JAX RS stuff is fine.What about the authentication aspects?
This is one of the hardest parts to get right when using OSLC to work with
IBM CLM integration, so I would prefer the newer client libraries did handle
the recommended authentication. In other words I completely agree with
your earlier statement that we should "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". I would interpret
that as a requirement either that client-core supports SSL, Basic and OpenIDConnect
authentication, or that authentication is split into another library with
one implementation providing such support. Separating the authentication
code might make that easier to update in the future.Nick.From:
"Jim Amsden"
<jamsden@xxxxxxxxxx>To:
Lyo project developer
discussions <lyo-dev@xxxxxxxxxxx>Date:
01/25/2019 05:34 AMSubject:
Re: [lyo-dev]
Migrating lyo.client from Wink to JerseySent by:
lyo-dev-bounces@xxxxxxxxxxx
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
Jim 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, PhDKTH Royal Institute of TechnologySchool of Industrial Engineering and Management,
Mechatronics DivisionBrinellvägen 83, SE-100 44 Stockholm, SwedenPhone: +46(0)8 790 6877 Mobile: +46(0)70
773 93 45jad@xxxxxx,
www.kth.se From:lyo-dev-bounces@xxxxxxxxxxx [mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Amsden
Sent: 24 January 2019 22:15
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: [lyo-dev] Migrating lyo.client from Wink to Jersey 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