On 2/6/2019 5:35 AM, Tim Ward via osgi-dev wrote:
Hi Bernd,
What you’re asking for isn’t a required part of the RSA standard,
which means that providers don’t have to offer it. There is, however,
room for it to exist within the standard.
OSGi Remote Services (and Remote Service Admin) define the concept of
“intents” which are additional features or qualities of service that a
distribution provider can offer. An example of an existing intent is
the “osgi.async” intent. This intent is used to indicate that the
distribution provider can handle asynchronous return types such as
OSGi Promises and Java futures. OSGi services that need to be remoted
can then require that the distribution provider offer the intent by
advertising the “service.exported.intents” property in addition to the
service.exported.interfaces property.
What you’re asking for is therefore an intent which provides security
context along with the call. I’m not aware of any distribution
provider that does this, but it would be possible for them to add it.
If they did they should add an advertised intent indicating the
support, and your service should then require the intent.
I’m not aware of any implementations that support security context
flow in this way currently.
ECF's implementation of remote services [1] has a distribution provider
spi, and multiple distribution providers [2]. Although we don't yet
have a OS distribution provider that supports exactly the desired
security context, many/most of the existing distribution providers are
extensible such that you could add your desired context to create a
custom distribution provider for your specific use (or open if you
desire). For example, you could use CXF or Jersey's extension
mechanisms by extending this provider [3].
Scott
[1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
[2] https://wiki.eclipse.org/Distribution_Providers
[3] https://github.com/ECF/JaxRSProviders (note: we are in the process
of updating the supported Jersey version from 2.22 -> 2.28)
Best Regards,
Tim
On 6 Feb 2019, at 13:13, Bernd Eckenfels via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
I guess most is thread local, it would be good if
extraction/marshaling and transport and demarshalling/setting on both
ends could be enhanced with interceptors.
But maybe a provide specific interface is enough? Did you do it for
Aeris RSA Fastbin?
Gruss
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
------------------------------------------------------------------------
*Von:* Christian Schneider <ch...@die-schneider.net
<mailto:ch...@die-schneider.net>>
*Gesendet:* Mittwoch, Februar 6, 2019 2:07 PM
*An:* Bernd Eckenfels; OSGi Developer Mail List
*Betreff:* Re: [osgi-dev] Remote service (thread) context properties?
JAAS is already standardised. So if the provider (like CXF SOAP or
JAX-RS) establishes a JAAS context on your thread then you can access
it. I can provide an example if you want.
I think for open tracing there is also an API that can be used.
I am not sure about the others like peer-address, audit, tenant and
request ids.
Do you have an idea how it can / should work in practice?
Christian
Am Mi., 6. Feb. 2019 um 03:08 Uhr schrieb Bernd Eckenfels via
osgi-dev <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>:
When I use a Remote Service for distributed OSGi application I
would like my provider to be able to implicitly pass some thread
context like tracing IDs and also a user authorization token.
The OSGi compendium talks about implementation specific security
based on codesigning, but not on thread identity (JAAS Context).
Was there any plan to add something, like an interceptor mechanism?
Some of it could be implementation specific, but some form of
portable endpoint binding access would be nice, like
peer-address, jaas-context, opentracing-id, maybe audit, tenant
and request-ids?
I can enrich my services with a Map<String,String> for most of
it, however then there is no reliable way for the provider to
add/ensure some of its protocol header properties and it hides
the business interface under removing parameters.
Gruss
Bernd
--
http://bernd.eckenfels.net <http://bernd.eckenfels.net/>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
--
Christian Schneider
http://www.liquid-reality.de <http://www.liquid-reality.de/>
Computer Scientist
http://www.adobe.com <http://www.adobe.com/>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
