Re: [lyo-dev] Client Authentication

["Jim Amsden" <jamsden@xxxxxxxxxx>]

Ralph,
We hope to be
able to provide a new OSLC client that uses JAX-RS 2.0 so that the authentication,
and secure connections needs can be configured by the clients themselves
(with suitable examples, many of which are outside the scope of OSLC).
Then these different approaches can be supported without putting them in
OSLC4J, reducing the coupling, increasing maintainability and providing
greater flexibility. These are often the good outcomes that result from
separation of concerns, while pushing some responsibility for configuration
back onto the client applications.


Jim Amsden, Senior
Technical Staff Member
OSLC and Linked Lifecycle
Data
919-525-6575




From:
       "Ralph
Schoon" <ralph.schoon@xxxxxxxxxx>
To:
       lyo-dev@xxxxxxxxxxx
Date:
       01/28/2019
08:32 AM
Subject:
       [lyo-dev]
Client Authentication
Sent
by:        lyo-dev-bounces@xxxxxxxxxxx

---

Jim,

we are starting to see bigger customers to begin with Kerberos and OpenIDConnect
(to support RTC Clustering). We see first integrations and tools struggling/failing
connecting to these servers. This is going to be a struggle.
It would be very useful, if the Lyo Client could support this somehow.
Users rely on this to be able to continue creating and using automation
tools and integrations.  

Mit freundlichen Grüßen / Kind regards

Ralph Schoon
"Unleash the Labs" - Watson IoT Connected Products
Leading Technical Sales Professional Client Technical Specialist Certified IT Specialist

E-Mail:	ralph.schoon@xxxxxxxxxx	IBM Deutschland
Mobile:	+49-170-4532-366	Wilhelm-Fay-Str. 30-34
		65936 Frankfurt
Blog:	http://rsjazz.wordpress.com/	Germany
IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Matthias Hartmann(Vorsitzender), Norbert Janzen, Nicole Reimer, Stefan Lutz, Wolfgang Wendt, Dr. Klaus Seifert Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 WEEE-Reg.-Nr. DE 99369940

From:        lyo-dev-request@xxxxxxxxxxx
To:        lyo-dev@xxxxxxxxxxx
Date:        25.01.2019
17:15
Subject:        lyo-dev
Digest, Vol 82, Issue 13
Sent by:        lyo-dev-bounces@xxxxxxxxxxx

---

Send lyo-dev mailing list submissions to
                lyo-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
                https://www.eclipse.org/mailman/listinfo/lyo-dev
or, via email, send a message with subject or body 'help' to
                lyo-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
                lyo-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lyo-dev digest..."


Today's Topics:

  1. Re: Migrating lyo.client from Wink to Jersey (Jim Amsden)


----------------------------------------------------------------------

Message: 1
Date: Fri, 25 Jan 2019 11:11:46 -0500
From: "Jim Amsden" <jamsden@xxxxxxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] Migrating lyo.client from Wink to Jersey
Message-ID:
                <OF41FA942F.1EEEDF1C-ON8525838D.0057DB32-8525838D.0058F7D7@xxxxxxxxxxxxxxxxxxxxxxx>
                
Content-Type: text/plain; charset="utf-8"

Nick,
Thanks for the feedback, you're opinion means a lot.

Re: authentication: there's perhaps a few approaches we could take.

1. its up to the client app - OslcClient(ClientBuilder) wouldn't provide
any authentication other than throwing an Unauthorized exception to the
client app. Client apps would be responsible for setting up a 
ClientBuilder or handling the authentication challenge exceptions that
met 
their needs.

This is easy for eclipse/Lyo, but pushes too much onto clients.

2. OslcClient(ClientBuilder, userID, password) would configure the REST
client, and be prepared to handle authentication challenges by examining
returned headers, and using the appropriate authentication technique to
respond to the challenge. It would be nice to support:
JEE Form
Basic
OAuth 1.0a
OpenIDConnect

This makes authentication transparent to the users, but would be a lot
of 
work for eclipse/Lyo, and might not handle all the cases.

3. A combination of the two where authentication challenges not handled
by 
OslcClient would be raised to the the client app, where additional 
ClientConfiguration of other approaches can deal with the challenge.

This could be a significant amount of work and testing. I wonder what the
demand is for this. Does anyone on this list want/need a new OSLC4J Java
Client? Would anyone be interested in contributing?



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:   "Nicholas Crossley" <nick_crossley@xxxxxxxxxx>
To:     Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date:   01/25/2019 10:03 AM
Subject:        Re: [lyo-dev] Migrating lyo.client
from Wink to Jersey
Sent by:        lyo-dev-bounces@xxxxxxxxxxx



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 AM
Subject:        Re: [lyo-dev] Migrating lyo.client
from Wink to Jersey
Sent 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, 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
jad@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%22/>
 <jfs:oauthUserAuthorizationUrl rdf:resource="
https://host:9443/iotp/services/oauth/authorize"
/>
 <jfs:oauthAccessTokenUrl rdf:resource="
https://host:9443/iotp/services/oauth/accessToken%22/>

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
_______________________________________________
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.eclipse.org/mailman/private/lyo-dev/attachments/20190125/0b78ea13/attachment.html>

------------------------------

_______________________________________________
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

End of lyo-dev Digest, Vol 82, Issue 13
***************************************



_______________________________________________
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