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. Best Regards, Tim > On 6 Feb 2019, at 13:13, Bernd Eckenfels via osgi-dev > <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> > 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 > <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 > 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
