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