Re: [osgi-dev] Remote service (thread) context properties?
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 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 <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 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 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
Re: [osgi-dev] Remote service (thread) context properties?
I dont think that the fastbin transport already has such integrations. If you want to work on this I can show how we support e.g. JAAS in CXF. Christian Am Mi., 6. Feb. 2019 um 14:13 Uhr schrieb Bernd Eckenfels < e...@zusammenkunft.net>: > 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 > *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>: > >> 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 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 >> ___ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Remote service (thread) context properties?
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 > 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 > 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 > 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 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
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>: > 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 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 > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Remote service (thread) context properties?
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 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 ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
