Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

Le 15 févr. 2018 01:35, "David Blevins"  a écrit :

I understand there's kind of a meta conversation going on that all roads
and discussions need to end at there being something to put a
microprofile-jwt git repo.  I wave a white flag and gently request a
respite from that as I don't want everything I write to be read as if I'm
attempting to steer for or against.

I'm 100% supportive of reuse.  And there could be something of value to
reuse in the end.  But at this moment if there was a microprofile-jwt git,
even if that repo was in TomEE, I'm not sold at this point there would be
enough code there to justify it.

I'd probably lean towards getting a prototype done with the mutual
understanding this part of the discussion is still open.  Once we have code
in hand, we can have a more informed discussion and circle back to reuse.

> On Feb 14, 2018, at 11:57 AM, Mark Struberg 
wrote:
>
> If you want to have JWT working for ALL EE things then it's not
MicroProfile-JWT anymore, isn't?
> It would be much more. Not bad of course, but still way beyond of what
MicroProfile-JWT defines.

Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
11 different integration points across JAX-RS, EJB, Servlets, JACC etc. As
only JAX-RS is a required part of a MicroProfile server and the other parts
are optional, at least 7 out of the 11 integration points are also optional.

There are tests for much of them in the MicroProfile JWT TCK. The tests are
also optional, but we'd definitely want to run and pass them as well as
contribute to them if they are incomplete.

If the spec is incomplete and we did miss an EE integration point,
definitely want to update the spec to cover it.  Scott and I and the other
folks who worked on the spec did our best to try and enumerate the ones we
could think of, but we may have missed some.

> Oh and I assume it does also include a way to _create_ JsonWebTokens,
right?

The token creation would be done by an OAuth provider, which is outside the
MP JWT specification.

The specification does have requirements that define what the token should
look like, but they're all very minimal so that we could be as compatible
as possible with as many existing OAuth provider implementations as
possible.

Effectively it says the JWT must be signed with an RSA private key the
OAuth Provider owns and assumes the MicroProfile server has been given the
public key.  How that public key is passed is also outside the
specification, but generally, it'll be on disk or sitting in the docker
image somewhere.


> * JSON-P on the json side.

Agree.  This is definitely mandatory to implement the MP JWT spec as claims
can be injected as JsonObject, etc.

> * crypto: Whether to use the JCE built-in crypto or an external lib
should be pluggable. We just need to add a smallish SPI with a few methods.

Agree to disagree on this one :)  JCE is an abstraction with two well known
impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so
not much complexity to abstract.

> * JsonWebToken and a way to get 'the' JWT for a single Request. That
might be a provider interface or a @RequestScoped CDI bean.

MP JWT spec requires there to be a dependent scoped producer for
JsonWebToken.  The bean getting JsonWebToken injected must be
RequestScoped.  Currently section 7.1.3 forbids injection into beans that
are not @RequestScoped.


Any waynto have a fixed spec saying it is not portable to not do so? Having
a deployment exception for a so common case is very rude and not justified
technically. Also using provider as a woraround is not mainstream and
generally way too slow.

Not that supporting CharSequence can be a smooth workaround for app scope
;).


With that in mind, I would probably implement JsonWebToken as an immutable
class -- i.e. get the token, then create the JsonWebToken and track that in
the request.  So ultimately the producer of JsonWebToken needs to get the
token from the request rather than the JsonWebToken implementation itself.


It is backed by jsonp so immutable by definition no?


Not yet discussed, but part of the spec is Claims can be injected as any
java type using the same conversion rules as MP Config.

Xbean-reflect has a large set of code for java-to-string conversion.  I
suspect geronimo-config as it's own implementation of java-to-string
conversion.  There's probably some opportunity for reuse consolidation
there.

Potentially even an option for a "Conversion" spec.  Andres was talking
about it at the last JCP EC event in London.  His JSR-377 (Desktop
Application Framework) apparently has similar needs.


Makes sense (and without any "context" please, this pollutes config spec
and makes it sadly not that portable :().



-David

Re: Implementing Microprofile JWT

[David Blevins]

I understand there's kind of a meta conversation going on that all roads and 
discussions need to end at there being something to put a microprofile-jwt git 
repo.  I wave a white flag and gently request a respite from that as I don't 
want everything I write to be read as if I'm attempting to steer for or against.

I'm 100% supportive of reuse.  And there could be something of value to reuse 
in the end.  But at this moment if there was a microprofile-jwt git, even if 
that repo was in TomEE, I'm not sold at this point there would be enough code 
there to justify it.

I'd probably lean towards getting a prototype done with the mutual 
understanding this part of the discussion is still open.  Once we have code in 
hand, we can have a more informed discussion and circle back to reuse.

> On Feb 14, 2018, at 11:57 AM, Mark Struberg  wrote:
> 
> If you want to have JWT working for ALL EE things then it's not 
> MicroProfile-JWT anymore, isn't? 
> It would be much more. Not bad of course, but still way beyond of what 
> MicroProfile-JWT defines.

Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about 11 
different integration points across JAX-RS, EJB, Servlets, JACC etc. As only 
JAX-RS is a required part of a MicroProfile server and the other parts are 
optional, at least 7 out of the 11 integration points are also optional.

There are tests for much of them in the MicroProfile JWT TCK. The tests are 
also optional, but we'd definitely want to run and pass them as well as 
contribute to them if they are incomplete.

If the spec is incomplete and we did miss an EE integration point, definitely 
want to update the spec to cover it.  Scott and I and the other folks who 
worked on the spec did our best to try and enumerate the ones we could think 
of, but we may have missed some.

> Oh and I assume it does also include a way to _create_ JsonWebTokens, right?

The token creation would be done by an OAuth provider, which is outside the MP 
JWT specification.

The specification does have requirements that define what the token should look 
like, but they're all very minimal so that we could be as compatible as 
possible with as many existing OAuth provider implementations as possible.

Effectively it says the JWT must be signed with an RSA private key the OAuth 
Provider owns and assumes the MicroProfile server has been given the public 
key.  How that public key is passed is also outside the specification, but 
generally, it'll be on disk or sitting in the docker image somewhere.


> * JSON-P on the json side.

Agree.  This is definitely mandatory to implement the MP JWT spec as claims can 
be injected as JsonObject, etc.

> * crypto: Whether to use the JCE built-in crypto or an external lib should be 
> pluggable. We just need to add a smallish SPI with a few methods.

Agree to disagree on this one :)  JCE is an abstraction with two well known 
impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so not 
much complexity to abstract.

> * JsonWebToken and a way to get 'the' JWT for a single Request. That might be 
> a provider interface or a @RequestScoped CDI bean. 

MP JWT spec requires there to be a dependent scoped producer for JsonWebToken.  
The bean getting JsonWebToken injected must be RequestScoped.  Currently 
section 7.1.3 forbids injection into beans that are not @RequestScoped.

With that in mind, I would probably implement JsonWebToken as an immutable 
class -- i.e. get the token, then create the JsonWebToken and track that in the 
request.  So ultimately the producer of JsonWebToken needs to get the token 
from the request rather than the JsonWebToken implementation itself.

Not yet discussed, but part of the spec is Claims can be injected as any java 
type using the same conversion rules as MP Config.

Xbean-reflect has a large set of code for java-to-string conversion.  I suspect 
geronimo-config as it's own implementation of java-to-string conversion.  
There's probably some opportunity for reuse consolidation there.

Potentially even an option for a "Conversion" spec.  Andres was talking about 
it at the last JCP EC event in London.  His JSR-377 (Desktop Application 
Framework) apparently has similar needs.


-David

Re: TomEE8 TCK status

[Romain Manni-Bucau]

2018-02-14 23:28 GMT+01:00 Mark Struberg :

> We now pass all tests in tck/cdi-embedded
> And we have only 3 failing tests in tck/cdi-tomee.
>
> 
> 
> 
>
> Those tests are all EAR related.
> Maybe they are only Arquillian adapter issues?
>

Don't think so, ear deployment is not that hacky in arquillian for tomee
remote and just reading the test names it can be actual bugs. I think they
are outside WP anyway so can be excluded but the first and the last ones
can need some love before the exclusions since we should support them. I'm
pretty sure we don't support the second one (yet).

Hope it helps


>
> LieGrue,
> strub
>
>
>
> > Am 08.02.2018 um 13:30 schrieb Mark Struberg  >:
> >
> > Well, this is why there are passivation listeners and stuff in the
> Servlet spec.
> >
> > We could easily also send a specific CDI event for it. But there is no
> such event in the CDI spec so far.
> > The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
> >
> > LieGrue,
> > strub
> >
> >> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Hmm, it is more vicious cause if the session is not destroyed you can
> still
> >> want to trigger this event. Guess it is another case where both cases
> are
> >> desirable (i want to clean up related state of the session...as well as
> I
> >> don't want to touch the session)...
> >>
> >> Since the appcontext destroy can be used as a workaround I think it is
> fine
> >> to challenge them now.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github  rmannibucau> |
> >> LinkedIn  | Book
> >>  ee-8-high-performance>
> >>
> >> 2018-02-08 11:37 GMT+01:00 Mark Struberg :
> >>
> >>> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
> SessionScoped.class)
> >>> and @Destroyed(SessionScoped.class) do work.
> >>> The tests itself are fine, but instead of relying that the sessions get
> >>> destroyed at server shutdown they could also have used
> >>> Session.invalidate()...
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
>  Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
>  :
> 
>  2018-02-08 11:28 GMT+01:00 Mark Struberg :
> 
> > All the embedded tests are now green.
> >
> > I'm now working on cdi-tomes (webprofile TCK).
> > So far we have 10 errors, but a few TCK tests are broken because they
> > wrongly assume that a container stop also kills the Session.
> >
> 
>  We can make them passing. We already did this kind of hack but since
> all
>  container have pluggability here - for good reasons - I agree they
>  shouldn't be in the TCK.
> 
> 
> > I've challenged those tests. Still have to review every red test...
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
> > matthew.broadh...@nbmlaw.co.uk>:
> >>
> >> nearly there!
> >>
> >> On 07/02/2018 11:57, Mark Struberg wrote:
> >>> [ERROR] Failures:
> >>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
> >>> [INFO]
> >>> [ERROR] Tests run: 1567, Failures: 1, Errors: 0, Skipped: 5
> >>>
> >>>
> >>> Wohuuu, 1 to go!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
>  Am 02.02.2018 um 21:54 schrieb Mark Struberg
> >>>  >> :
> 
>  And the last status:
> 
>  [ERROR] Failures:
>  [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
>  [ERROR]   ContainerLifeCycleEventRuntime
> InvocationTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
>  [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
> > interceptedBeanForEEComponentIsNullInInterceptor:61 expected [true]
> but
> > found [false]
>  [INFO]
>  [ERROR] Tests run: 1570, Failures: 3, Errors: 0, Skipped: 22
> 
>  Reminder: this is for cdi-embedded only for now.
>  But once we are through that the rest is usually much easier.
> 
>  LieGrue,
>  strub
> 
> 
> 
> > Am 01.02.2018 um 23:18 schrieb Mark Struberg  >:
> >
> > We are moving...
> >
> > [ERROR] Failures:
> > [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
> > [ERROR]   ObserverMethodInvocationContex
> tTest>Arquillian.run:164->
> > testTransactionalObserverMethod:55 » EJB
> > [ERROR]   SessionBeanObserverMethodInvoc
> >>> ationContextTest>Arquillian.
> > run:164->testTransact

Re: TomEE8 TCK status

[Mark Struberg]

We now pass all tests in tck/cdi-embedded
And we have only 3 failing tests in tck/cdi-tomee. 





Those tests are all EAR related.
Maybe they are only Arquillian adapter issues?

LieGrue,
strub



> Am 08.02.2018 um 13:30 schrieb Mark Struberg :
> 
> Well, this is why there are passivation listeners and stuff in the Servlet 
> spec.
> 
> We could easily also send a specific CDI event for it. But there is no such 
> event in the CDI spec so far.
> The @Destryoed and @BeforeDestroyed are specifically for _destroyal_. 
> 
> LieGrue,
> strub
> 
>> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau :
>> 
>> Hmm, it is more vicious cause if the session is not destroyed you can still
>> want to trigger this event. Guess it is another case where both cases are
>> desirable (i want to clean up related state of the session...as well as I
>> don't want to touch the session)...
>> 
>> Since the appcontext destroy can be used as a workaround I think it is fine
>> to challenge them now.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github  
>> |
>> LinkedIn  | Book
>> 
>> 
>> 2018-02-08 11:37 GMT+01:00 Mark Struberg :
>> 
>>> Yea, it's mainly testing whether the @Observes 
>>> @BeforeDestroyed(SessionScoped.class)
>>> and @Destroyed(SessionScoped.class) do work.
>>> The tests itself are fine, but instead of relying that the sessions get
>>> destroyed at server shutdown they could also have used
>>> Session.invalidate()...
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
 Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau >>> :
 
 2018-02-08 11:28 GMT+01:00 Mark Struberg :
 
> All the embedded tests are now green.
> 
> I'm now working on cdi-tomes (webprofile TCK).
> So far we have 10 errors, but a few TCK tests are broken because they
> wrongly assume that a container stop also kills the Session.
> 
 
 We can make them passing. We already did this kind of hack but since all
 container have pluggability here - for good reasons - I agree they
 shouldn't be in the TCK.
 
 
> I've challenged those tests. Still have to review every red test...
> 
> LieGrue,
> strub
> 
> 
>> Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk>:
>> 
>> nearly there!
>> 
>> On 07/02/2018 11:57, Mark Struberg wrote:
>>> [ERROR] Failures:
>>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
>>> arquillianBeforeClass:109
> » Deployment
>>> [INFO]
>>> [ERROR] Tests run: 1567, Failures: 1, Errors: 0, Skipped: 5
>>> 
>>> 
>>> Wohuuu, 1 to go!
>>> 
>>> LieGrue,
>>> strub
>>> 
 Am 02.02.2018 um 21:54 schrieb Mark Struberg
>>> > :
 
 And the last status:
 
 [ERROR] Failures:
 [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
>>> arquillianBeforeClass:109
> » Deployment
 [ERROR]   ContainerLifeCycleEventRuntimeInvocationTest>Arquillian.
>>> arquillianBeforeClass:109
> » Deployment
 [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
> interceptedBeanForEEComponentIsNullInInterceptor:61 expected [true] but
> found [false]
 [INFO]
 [ERROR] Tests run: 1570, Failures: 3, Errors: 0, Skipped: 22
 
 Reminder: this is for cdi-embedded only for now.
 But once we are through that the rest is usually much easier.
 
 LieGrue,
 strub
 
 
 
> Am 01.02.2018 um 23:18 schrieb Mark Struberg :
> 
> We are moving...
> 
> [ERROR] Failures:
> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
>>> arquillianBeforeClass:109
> » Deployment
> [ERROR]   ObserverMethodInvocationContextTest>Arquillian.run:164->
> testTransactionalObserverMethod:55 » EJB
> [ERROR]   SessionBeanObserverMethodInvoc
>>> ationContextTest>Arquillian.
> run:164->testTransactionalObserverMethod:55 » EJB
> [ERROR]   SessionBeanStaticObserverMethodInvocationContextTest>
> Arquillian.run:164->testTransactionalObserverMethod:55 » EJB
> [ERROR]   ContainerLifeCycleEventRuntimeInvocationTest>Arquillian.
>>> arquillianBeforeClass:109
> » Deployment
> [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
> interceptedBeanForEEComponentIsNullInInterceptor:61 expected [true] but
> found [false]
> [INFO]
> [ERROR] Tests run: 1573, Failures: 6, Errors: 0, Skipped: 22
> 
> 
> 
> 
> On Thursday, 1 February 2018, 14:37:17 CET, Mark Struberg
>  wrote:
> 
> 
> With 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

We propagate to EJB the principal so we should have it working without a
lot - never said "no" - of effort for all synchronous cases. I'm pretty
sure it will be broken for the async - but natural user - flow (@Suspended
or plain AsyncContext, EE Concurrency utilities will not work for servlet
case - can need a fix - but would if called from an EJB IIRC) but this
seems out of the spec too, no?

You are right the Jacc integration can need a few more love to match the
spec but we own this code and have the principal at that moment so i'm sure
we can make it running, even without being jwt specific which can benefit
all the alternative solutions user base.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-14 22:43 GMT+01:00 David Blevins :

> > On Feb 14, 2018, at 11:34 AM, Romain Manni-Bucau 
> wrote:
> >
> > If jsonp it can be @appscoped too technically
>
> I was definitely advocating for that and AppScoped was supported, but it
> got axed at the finish line the week before the 1.0 spec went final.  We
> decided to cut scope (pun intended) to get something out the door and come
> back and add this later.
>
> > > That part will be a bit tricky, but effectively we need a
> dependent-scoped
> > > producer that can find the JWT data in the active request.  Perhaps by
> > > looking in the ThreadContext.
> >
> > Cant jaspic work?
>
> Not sure to be honest.
>
> One place I suspect will be tough is the EJB isCallerInRole checks we do
> are effectively handled by our JACC code (or was).  That code expects we
> know all the users that exist and their permissions at startup time.
> During the Assembler phase the JaccPermissionsBuilder will build a
> permissions object for each role the user has.  The JACC provider then
> becomes effectively an in memory database of permissions objects.  This
> again, goes against the JWT concept as the user and the roles are in the
> token and there is no state in the server.
>
> Not sure how we'll need to handle that or if JASPIC helps.
>
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/java/org/apache/openejb/assembler/classic/
> JaccPermissionsBuilder.java
>
> > Also a jwt for an ejb without a request
> > meanssomething to define ;).
>
> That's all defined in chapter 12
>
>  ... the spec may or may not have only 10 chapters :)
>
>
> -David
>
>
>
>

Re: Implementing Microprofile JWT

[David Blevins]

> On Feb 14, 2018, at 11:34 AM, Romain Manni-Bucau  
> wrote:
> 
> If jsonp it can be @appscoped too technically

I was definitely advocating for that and AppScoped was supported, but it got 
axed at the finish line the week before the 1.0 spec went final.  We decided to 
cut scope (pun intended) to get something out the door and come back and add 
this later.

> > That part will be a bit tricky, but effectively we need a dependent-scoped
> > producer that can find the JWT data in the active request.  Perhaps by
> > looking in the ThreadContext.
> 
> Cant jaspic work?

Not sure to be honest.

One place I suspect will be tough is the EJB isCallerInRole checks we do are 
effectively handled by our JACC code (or was).  That code expects we know all 
the users that exist and their permissions at startup time.  During the 
Assembler phase the JaccPermissionsBuilder will build a permissions object for 
each role the user has.  The JACC provider then becomes effectively an in 
memory database of permissions objects.  This again, goes against the JWT 
concept as the user and the roles are in the token and there is no state in the 
server.

Not sure how we'll need to handle that or if JASPIC helps.


https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JaccPermissionsBuilder.java

> Also a jwt for an ejb without a request
> meanssomething to define ;).

That's all defined in chapter 12

 ... the spec may or may not have only 10 chapters :)


-David

Re: IP Clearance for Sheldon and Chatterbox

[Jean-Louis Monteiro]

Yes, I have created a PR for both so they are ready for review.
I have done everything that came to my mind in terms of updates.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Wed, Feb 14, 2018 at 9:54 PM, John D. Ament 
wrote:

> Sorry I got dropped along the way (and am not subscribed to your dev
> list).  I believe both projects are already in public repos, so keeping
> there would be fine.  The most important part is getting the IP Clearance
> started in the incubator.
>
> As far as moving the repos, its just an infra ticket (once the IP
> clearance is done) requesting moving the repos.  One of the infra admins
> will ask to be made an admin in your repo and will execute the move once
> done.
>
> On 2018/02/13 23:12:09, Jonathan Gallimore 
> wrote:
> > Can you post where we need to review? I'm more than happy to help with
> the
> > review process.
> >
> > Jon
> >
> > On Tue, Feb 13, 2018 at 8:56 PM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > John, I have both cleaned up with the right headers, notice and license
> > > files.
> > > It's ready for review. I'll be creating the git repos tonight and push
> > > sources for review in a tomitribe repo.
> > >
> > > As soon as everyone is happy we can do the actual import @Apache
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > > On Tue, Feb 13, 2018 at 6:55 PM, David Blevins <
> david.blev...@gmail.com>
> > > wrote:
> > >
> > > > Thanks, John.
> > > >
> > > > > On Feb 13, 2018, at 9:43 AM, John D. Ament 
> > > > wrote:
> > > > >
> > > > > The overall IP Clearance process can be found at [2].  Someone will
> > > need
> > > > to
> > > > > commit the necessary files, call the vote etc.  I would recommend
> > > > separate
> > > > > IP Clearances for each component.  I believe I would be comfortable
> > > > > pointing to specific git hashes for the import, assuming you would
> want
> > > > to
> > > > > have infra just move the repos from tomitribe to apache on github,
> > > > instead
> > > > > of recreating the repos (helps keep the stars and forks in sync).
> > > >
> > > > Moving the repos is ideal if we could do that.  Then github will
> > > redirect.
> > > >
> > > > How do we execute that option?
> > > >
> > > >
> > > > -David
> > > >
> > > >
> > >
> >
>

Re: IP Clearance for Sheldon and Chatterbox

[John D . Ament]

Sorry I got dropped along the way (and am not subscribed to your dev list).  I 
believe both projects are already in public repos, so keeping there would be 
fine.  The most important part is getting the IP Clearance started in the 
incubator.

As far as moving the repos, its just an infra ticket (once the IP clearance is 
done) requesting moving the repos.  One of the infra admins will ask to be made 
an admin in your repo and will execute the move once done.

On 2018/02/13 23:12:09, Jonathan Gallimore  
wrote: 
> Can you post where we need to review? I'm more than happy to help with the
> review process.
> 
> Jon
> 
> On Tue, Feb 13, 2018 at 8:56 PM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> 
> > John, I have both cleaned up with the right headers, notice and license
> > files.
> > It's ready for review. I'll be creating the git repos tonight and push
> > sources for review in a tomitribe repo.
> >
> > As soon as everyone is happy we can do the actual import @Apache
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 6:55 PM, David Blevins 
> > wrote:
> >
> > > Thanks, John.
> > >
> > > > On Feb 13, 2018, at 9:43 AM, John D. Ament 
> > > wrote:
> > > >
> > > > The overall IP Clearance process can be found at [2].  Someone will
> > need
> > > to
> > > > commit the necessary files, call the vote etc.  I would recommend
> > > separate
> > > > IP Clearances for each component.  I believe I would be comfortable
> > > > pointing to specific git hashes for the import, assuming you would want
> > > to
> > > > have infra just move the repos from tomitribe to apache on github,
> > > instead
> > > > of recreating the repos (helps keep the stars and forks in sync).
> > >
> > > Moving the repos is ideal if we could do that.  Then github will
> > redirect.
> > >
> > > How do we execute that option?
> > >
> > >
> > > -David
> > >
> > >
> >
> 

Re: Implementing Microprofile JWT

[Mark Struberg]

If you want to have JWT working for ALL EE things then it's not 
MicroProfile-JWT anymore, isn't? 
It would be much more. Not bad of course, but still way beyond of what 
MicroProfile-JWT defines.

Anyway, I asked myself how to 'slice' this the right way.
And imo the natural interfaces would be somthing like

* JSON-P on the json side. 
* crypto: Whether to use the JCE built-in crypto or an external lib should be 
pluggable. We just need to add a smallish SPI with a few methods.
* JsonWebToken and a way to get 'the' JWT for a single Request. That might be a 
provider interface or a @RequestScoped CDI bean. 

Oh and I assume it does also include a way to _create_ JsonWebTokens, right?
Could not find this part in the microprofile-jwt discussion/source. Anyone?

But apart from that that's it!

Everything else - including HttpServletRequest Principal, EJB isUserInRole, etc 
is an integration aspect in other parts!
The microprofil-jwt impl is perfectly agnostic to TomEE nor anything else. The 
integration and propagation to all the other EE parts is an integration task 
into TomEE. 

If we cut it that way we have a rather cleanish API which we can easily 
maintain in the future. 
If we start to bake in TomEE features into the mp-jwt core then welcome to 
monolith scariness I'd say.


> to be injected into @RequestScoped beans
not injected INTO, but the information itself is provided as @RequestScoped 
bean.
Of course you can inject it into anything actually. 


> That part will be a bit tricky, but effectively we need a dependent-scoped
> producer that can find the JWT data in the active request.  Perhaps by
> looking in the ThreadContext.
Yes, of course the JWT is request scoped. Taken from a HTTP header in a 
ServletFilter usually.

wdyt?

LieGrue,
strub



> Am 14.02.2018 um 19:19 schrieb David Blevins :
> 
>> On Feb 14, 2018, at 8:49 AM, Mark Struberg  wrote:
>> 
>>> 
>>> I think one of the things we'll find most puzzling about how to do the 
>>> integration is that the Tomcat flavor of this is written assuming the users 
>>> exist in a Tomcat Realm.  The whole point of JWT is that they do not and 
>>> the server has no such state.
>>> 
>>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
>>> 
>>> I think we'll grapple with questions like "should we support some local 
>>> override if the user happens to exist locally?"  Certainly, we could.  I 
>>> might suggest we don't for the first prototype and add that later.
>> 
>> Didn't think about this yet, but I assume that's because their contract is 
>> to keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, 
>> even for JWT?
> 
> Correct.
> 
>> Don't know from the back of my mind about the MicroProfile-JWT contract. But 
>> MicroProfile NOT being based on Servlets I assume they have just an 
>> @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].
>> 
>> While this extends Principal I still think it will be hard to tweak 
>> HttpServletRequest to work with it.
>> But do we? 
> 
> We do, yes.
> 
> You're correct in that MicroProfile itself doesn't include Servlets, EJB, 
> etc. but making sure JWTs worked for those things is definitely what we were 
> trying to do in defining the spec.  The goal is that 100% of the security 
> concepts in Java EE would work against a JWT; EJB isCallerInRole, EJB 
> @RolesAllowed, Servlet getCallerPrincipal, exposing a JWT as a Principal, a 
> few new Java EE Security calls, etc.
> 
> The fact that MicroProfile itself doesn't require the specs for all the touch 
> points we needed/wanted was handled by effectively making all those things 
> optional.  Despite them being optional, we tried to phrase it like "if you do 
> implement it, it should work like this" and there are TCK tests to go along 
> with a good chunk of it.
> 
> We were very much trying to define EE security as it pertains to JWT, while 
> doing our best to navigate the Java EE and MicroProfile relationship.
> 
> Now that EE is moving to Eclipse, EE Security and MicroProfile JWT security 
> are highly likely to meld in some way.
> 
> 
> -David

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

Le 14 févr. 2018 19:47, "David Blevins"  a écrit :

> On Feb 14, 2018, at 9:01 AM, Romain Manni-Bucau 
wrote:
>
> interesting thing is JsonWebToken principal will not work with CDI by
> design - due to proxies - so must use another unwrapped layer to get the
> principal like jaspic or servlet layers which will not require any change
> in any of our internals but more a better integration of existing techno,
> no?

There are effectively two ways to get the JsonWebToken:

 - Injectable via CDI into @RequestScoped beans
 - Anywhere a Principal can be obtained

There is also an @Claim qualifier which allows individual claims from the
JWT to be injected into @RequestScoped beans as JSON-P types or as
primatives.


If jsonp it can be @appscoped too technically


That part will be a bit tricky, but effectively we need a dependent-scoped
producer that can find the JWT data in the active request.  Perhaps by
looking in the ThreadContext.


Cant jaspic work? Also a jwt for an ejb without a request
meanssomething to define ;).



-David

Re: Implementing Microprofile JWT

[David Blevins]

> On Feb 14, 2018, at 9:01 AM, Romain Manni-Bucau  wrote:
> 
> interesting thing is JsonWebToken principal will not work with CDI by
> design - due to proxies - so must use another unwrapped layer to get the
> principal like jaspic or servlet layers which will not require any change
> in any of our internals but more a better integration of existing techno,
> no?

There are effectively two ways to get the JsonWebToken:

 - Injectable via CDI into @RequestScoped beans
 - Anywhere a Principal can be obtained

There is also an @Claim qualifier which allows individual claims from the JWT 
to be injected into @RequestScoped beans as JSON-P types or as primatives.

That part will be a bit tricky, but effectively we need a dependent-scoped 
producer that can find the JWT data in the active request.  Perhaps by looking 
in the ThreadContext.


-David

Re: Implementing Microprofile JWT

[David Blevins]

> On Feb 14, 2018, at 8:49 AM, Mark Struberg  wrote:
> 
>> 
>> I think one of the things we'll find most puzzling about how to do the 
>> integration is that the Tomcat flavor of this is written assuming the users 
>> exist in a Tomcat Realm.  The whole point of JWT is that they do not and the 
>> server has no such state.
>> 
>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
>> 
>> I think we'll grapple with questions like "should we support some local 
>> override if the user happens to exist locally?"  Certainly, we could.  I 
>> might suggest we don't for the first prototype and add that later.
> 
> Didn't think about this yet, but I assume that's because their contract is to 
> keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, even 
> for JWT?

Correct.

> Don't know from the back of my mind about the MicroProfile-JWT contract. But 
> MicroProfile NOT being based on Servlets I assume they have just an 
> @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].
> 
> While this extends Principal I still think it will be hard to tweak 
> HttpServletRequest to work with it.
> But do we? 

We do, yes.

You're correct in that MicroProfile itself doesn't include Servlets, EJB, etc. 
but making sure JWTs worked for those things is definitely what we were trying 
to do in defining the spec.  The goal is that 100% of the security concepts in 
Java EE would work against a JWT; EJB isCallerInRole, EJB @RolesAllowed, 
Servlet getCallerPrincipal, exposing a JWT as a Principal, a few new Java EE 
Security calls, etc.

The fact that MicroProfile itself doesn't require the specs for all the touch 
points we needed/wanted was handled by effectively making all those things 
optional.  Despite them being optional, we tried to phrase it like "if you do 
implement it, it should work like this" and there are TCK tests to go along 
with a good chunk of it.

We were very much trying to define EE security as it pertains to JWT, while 
doing our best to navigate the Java EE and MicroProfile relationship.

Now that EE is moving to Eclipse, EE Security and MicroProfile JWT security are 
highly likely to meld in some way.


-David

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

think we support jaspic at some point - at least javaee 7 tests were
supposed to cover it, even for EJB while there is a request - not for
@Timeout typically but this is out of scope for microprofile.

interesting thing is JsonWebToken principal will not work with CDI by
design - due to proxies - so must use another unwrapped layer to get the
principal like jaspic or servlet layers which will not require any change
in any of our internals but more a better integration of existing techno,
no?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-14 17:54 GMT+01:00 Jean-Louis Monteiro :

> Thanks David,
>
> I've started to look into our SecurityService interface as well.
> It would need to evolve at some point. The couple username + password is
> not the best to support many authentication mechanisms.
>
> The realm interface in Tomcat is not the best either because it has like 5
> or 6 strongly typed signatures and you can't add more.
> Basically currently, I'll pass the token into the username parameter and
> leave the password empty.
>
> But would be great to think about a better abstraction to represent the
> credentials.
>
> On the prototype side, I'll definitely use Nimbus to start.
> Don't want to address all problems at once.
>
> Rudy has one implementation based on JASPIC, probably a good opportunity to
> look at it.
>
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, Feb 14, 2018 at 5:30 PM, David Blevins 
> wrote:
>
> >
> > > On Feb 13, 2018, at 3:43 AM, John D. Ament 
> > wrote:
> > >
> > > The JWT spec is weird, because it defined non MP runtime behavior in
> > addition to MP runtime behavior; so there may be more integration work
> in a
> > fuller app server like TomEE.
> >
> > Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
> >
> > There are also optional integration parts for EJB which I think we'd
> > definitely implement.
> >
> > > On Feb 13, 2018, at 6:53 AM, Mark Struberg 
> > wrote:
> > >
> > > I know JWT a bit and I wonder whether doing the signing part is just a
> > bit of Json (JSON-P) + commons-crypto?
> > > After all JWT is especially designed to be lightweight and straight
> > forward.
> >
> > Agreed.  We could definitely get by with JSON-P and even the built-in JVM
> > crypto.  No need for commons-crypto.
> >
> > The MicroProfile JWT specification is intentionally "opinionated" about
> > the JWT format and only allows for compact JWTs and RSA signatures.  The
> > actual JOSE specifications allow for much greater flexibility and
> options,
> > which is why libraries like Nimbus exist.
> >
> > That said, I would still probably prototype with Nimbus and cut it out
> > only after everything works.  Just to make sure I was focusing on the
> right
> > part of the problem.
> >
> > > On Feb 13, 2018, at 7:58 AM, Mark Struberg 
> > wrote:
> > >
> > > I'm more worried about the authorisation and authentication interface.
> > > Anything EE security seems way too heavyweight for me. This might work
> > out for TomEE, but would kill it's use in any more lightweight approach.
> >
> > > On Feb 13, 2018, at 11:27 AM, Rudy De Busscher 
> > wrote:
> > >
> > > I used JASPIC as it seemed to most natural way to feed the EE system
> > > with authorisation
> > > and authentication into the system.
> > >
> > > But probably need deep integration with server code because otherwise,
> > the
> > > JWT authentication mechanism is an all or nothing system, which is not
> > the
> > > best solution (maybe less a problem with MicroServices but if you want
> to
> > > use it in a more general way it is an obstacle)
> >
> > These last two are very related.  JASPIC would be great, but TomEE
> > (specifically the OpenEJB part) doesn't implement it.  All of the EJB
> calls
> > for isCallerInRole etc are wired in and fed through this interface.
> >
> > https://github.com/apache/tomee/blob/master/container/
> > openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
> >
> > I think one of the things we'll find most puzzling about how to do the
> > integration is that the Tomcat flavor of this is written assuming the
> users
> > exist in a Tomcat Realm.  The whole point of JWT is that they do not and
> > the server has no such state.
> >
> > https://github.com/apache/tomee/blob/master/tomee/tomee-
> > catalina/src/main/java/org/apache/tomee/catalina/
> > TomcatSecurityService.java
> >
> > I think we'll grapple with questions like "should we support some local
> > override if the user happens to exist locally?"  Certainly, we could.  I
> > might suggest we don't for the first prototype and add that later.
> >
> >
> > -David
> >
> >

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

Thanks David,

I've started to look into our SecurityService interface as well.
It would need to evolve at some point. The couple username + password is
not the best to support many authentication mechanisms.

The realm interface in Tomcat is not the best either because it has like 5
or 6 strongly typed signatures and you can't add more.
Basically currently, I'll pass the token into the username parameter and
leave the password empty.

But would be great to think about a better abstraction to represent the
credentials.

On the prototype side, I'll definitely use Nimbus to start.
Don't want to address all problems at once.

Rudy has one implementation based on JASPIC, probably a good opportunity to
look at it.








--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Wed, Feb 14, 2018 at 5:30 PM, David Blevins 
wrote:

>
> > On Feb 13, 2018, at 3:43 AM, John D. Ament 
> wrote:
> >
> > The JWT spec is weird, because it defined non MP runtime behavior in
> addition to MP runtime behavior; so there may be more integration work in a
> fuller app server like TomEE.
>
> Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
>
> There are also optional integration parts for EJB which I think we'd
> definitely implement.
>
> > On Feb 13, 2018, at 6:53 AM, Mark Struberg 
> wrote:
> >
> > I know JWT a bit and I wonder whether doing the signing part is just a
> bit of Json (JSON-P) + commons-crypto?
> > After all JWT is especially designed to be lightweight and straight
> forward.
>
> Agreed.  We could definitely get by with JSON-P and even the built-in JVM
> crypto.  No need for commons-crypto.
>
> The MicroProfile JWT specification is intentionally "opinionated" about
> the JWT format and only allows for compact JWTs and RSA signatures.  The
> actual JOSE specifications allow for much greater flexibility and options,
> which is why libraries like Nimbus exist.
>
> That said, I would still probably prototype with Nimbus and cut it out
> only after everything works.  Just to make sure I was focusing on the right
> part of the problem.
>
> > On Feb 13, 2018, at 7:58 AM, Mark Struberg 
> wrote:
> >
> > I'm more worried about the authorisation and authentication interface.
> > Anything EE security seems way too heavyweight for me. This might work
> out for TomEE, but would kill it's use in any more lightweight approach.
>
> > On Feb 13, 2018, at 11:27 AM, Rudy De Busscher 
> wrote:
> >
> > I used JASPIC as it seemed to most natural way to feed the EE system
> > with authorisation
> > and authentication into the system.
> >
> > But probably need deep integration with server code because otherwise,
> the
> > JWT authentication mechanism is an all or nothing system, which is not
> the
> > best solution (maybe less a problem with MicroServices but if you want to
> > use it in a more general way it is an obstacle)
>
> These last two are very related.  JASPIC would be great, but TomEE
> (specifically the OpenEJB part) doesn't implement it.  All of the EJB calls
> for isCallerInRole etc are wired in and fed through this interface.
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
>
> I think one of the things we'll find most puzzling about how to do the
> integration is that the Tomcat flavor of this is written assuming the users
> exist in a Tomcat Realm.  The whole point of JWT is that they do not and
> the server has no such state.
>
> https://github.com/apache/tomee/blob/master/tomee/tomee-
> catalina/src/main/java/org/apache/tomee/catalina/
> TomcatSecurityService.java
>
> I think we'll grapple with questions like "should we support some local
> override if the user happens to exist locally?"  Certainly, we could.  I
> might suggest we don't for the first prototype and add that later.
>
>
> -David
>
>

Re: Implementing Microprofile JWT

[Mark Struberg]

> 
> I think one of the things we'll find most puzzling about how to do the 
> integration is that the Tomcat flavor of this is written assuming the users 
> exist in a Tomcat Realm.  The whole point of JWT is that they do not and the 
> server has no such state.
> 
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
> 
> I think we'll grapple with questions like "should we support some local 
> override if the user happens to exist locally?"  Certainly, we could.  I 
> might suggest we don't for the first prototype and add that later.

Didn't think about this yet, but I assume that's because their contract is to 
keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, even for 
JWT?
Don't know from the back of my mind about the MicroProfile-JWT contract. But 
MicroProfile NOT being based on Servlets I assume they have just an 
@Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].

While this extends Principal I still think it will be hard to tweak 
HttpServletRequest to work with it.
But do we? 

LieGrue,
strub

[1] 
https://github.com/eclipse/microprofile-jwt-auth/blob/master/api/src/main/java/org/eclipse/microprofile/jwt/JsonWebToken.java


> Am 14.02.2018 um 17:30 schrieb David Blevins :
> 
> 
>> On Feb 13, 2018, at 3:43 AM, John D. Ament  wrote:
>> 
>> The JWT spec is weird, because it defined non MP runtime behavior in 
>> addition to MP runtime behavior; so there may be more integration work in a 
>> fuller app server like TomEE.
> 
> Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
> 
> There are also optional integration parts for EJB which I think we'd 
> definitely implement.
> 
>> On Feb 13, 2018, at 6:53 AM, Mark Struberg  wrote:
>> 
>> I know JWT a bit and I wonder whether doing the signing part is just a bit 
>> of Json (JSON-P) + commons-crypto?
>> After all JWT is especially designed to be lightweight and straight forward.
> 
> Agreed.  We could definitely get by with JSON-P and even the built-in JVM 
> crypto.  No need for commons-crypto.
> 
> The MicroProfile JWT specification is intentionally "opinionated" about the 
> JWT format and only allows for compact JWTs and RSA signatures.  The actual 
> JOSE specifications allow for much greater flexibility and options, which is 
> why libraries like Nimbus exist.
> 
> That said, I would still probably prototype with Nimbus and cut it out only 
> after everything works.  Just to make sure I was focusing on the right part 
> of the problem.
> 
>> On Feb 13, 2018, at 7:58 AM, Mark Struberg  wrote:
>> 
>> I'm more worried about the authorisation and authentication interface. 
>> Anything EE security seems way too heavyweight for me. This might work out 
>> for TomEE, but would kill it's use in any more lightweight approach.
> 
>> On Feb 13, 2018, at 11:27 AM, Rudy De Busscher  wrote:
>> 
>> I used JASPIC as it seemed to most natural way to feed the EE system
>> with authorisation
>> and authentication into the system.
>> 
>> But probably need deep integration with server code because otherwise, the
>> JWT authentication mechanism is an all or nothing system, which is not the
>> best solution (maybe less a problem with MicroServices but if you want to
>> use it in a more general way it is an obstacle)
> 
> These last two are very related.  JASPIC would be great, but TomEE 
> (specifically the OpenEJB part) doesn't implement it.  All of the EJB calls 
> for isCallerInRole etc are wired in and fed through this interface.
> 
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
> 
> I think one of the things we'll find most puzzling about how to do the 
> integration is that the Tomcat flavor of this is written assuming the users 
> exist in a Tomcat Realm.  The whole point of JWT is that they do not and the 
> server has no such state.
> 
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
> 
> I think we'll grapple with questions like "should we support some local 
> override if the user happens to exist locally?"  Certainly, we could.  I 
> might suggest we don't for the first prototype and add that later.
> 
> 
> -David
> 

Re: Implementing Microprofile JWT

[David Blevins]

> On Feb 13, 2018, at 3:43 AM, John D. Ament  wrote:
> 
> The JWT spec is weird, because it defined non MP runtime behavior in addition 
> to MP runtime behavior; so there may be more integration work in a fuller app 
> server like TomEE.

Agreed. I'd describe the MicorProfile JWT spec as almost all integration.

There are also optional integration parts for EJB which I think we'd definitely 
implement.

> On Feb 13, 2018, at 6:53 AM, Mark Struberg  wrote:
> 
> I know JWT a bit and I wonder whether doing the signing part is just a bit of 
> Json (JSON-P) + commons-crypto?
> After all JWT is especially designed to be lightweight and straight forward.

Agreed.  We could definitely get by with JSON-P and even the built-in JVM 
crypto.  No need for commons-crypto.

The MicroProfile JWT specification is intentionally "opinionated" about the JWT 
format and only allows for compact JWTs and RSA signatures.  The actual JOSE 
specifications allow for much greater flexibility and options, which is why 
libraries like Nimbus exist.

That said, I would still probably prototype with Nimbus and cut it out only 
after everything works.  Just to make sure I was focusing on the right part of 
the problem.

> On Feb 13, 2018, at 7:58 AM, Mark Struberg  wrote:
> 
> I'm more worried about the authorisation and authentication interface. 
> Anything EE security seems way too heavyweight for me. This might work out 
> for TomEE, but would kill it's use in any more lightweight approach.

> On Feb 13, 2018, at 11:27 AM, Rudy De Busscher  wrote:
> 
> I used JASPIC as it seemed to most natural way to feed the EE system
> with authorisation
> and authentication into the system.
> 
> But probably need deep integration with server code because otherwise, the
> JWT authentication mechanism is an all or nothing system, which is not the
> best solution (maybe less a problem with MicroServices but if you want to
> use it in a more general way it is an obstacle)

These last two are very related.  JASPIC would be great, but TomEE 
(specifically the OpenEJB part) doesn't implement it.  All of the EJB calls for 
isCallerInRole etc are wired in and fed through this interface.

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java

I think one of the things we'll find most puzzling about how to do the 
integration is that the Tomcat flavor of this is written assuming the users 
exist in a Tomcat Realm.  The whole point of JWT is that they do not and the 
server has no such state.

https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java

I think we'll grapple with questions like "should we support some local 
override if the user happens to exist locally?"  Certainly, we could.  I might 
suggest we don't for the first prototype and add that later.


-David

Re: Implementing Microprofile JWT

[David Blevins]

Can you put that on the Umbrella thread?  More for clean archiving and 
collecting everything in one spot.


-David

> On Feb 13, 2018, at 8:25 AM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> Mike had a grat response on the imact and potential downsides of becoming an 
> Umbrella project.
> I asked for his permisson to forward, so here we go.
> Txs Mike for the additional input!
> 
> LieGrue,
> strub
> 
> 
>> 
>> Von: Mike Kienenberger 
>> Betreff: Aw: Implementing Microprofile JWT
>> Datum: 13. Februar 2018 um 16:08:24 MEZ
>> An: bo...@apache.org
>> 
>> As the Chair of an umbrella project (MyFaces), I strongly recommend
>> against making umbrella projects.
>> 
>> Umbrella projects end up with a lot of unloved components, and this
>> happens without anyone realizing it as it is difficult to have the
>> same oversight for subprojects as there is for a TLP.
>> 
>> There is going to be some point where smaller items are too small to
>> handle individually, but you should have the mindset that whenever a
>> subproject gets enough community to support it that it should
>> immediately spin off to its own TLP.
>> 
>> Right now, MyFaces has 11 subprojects.   Only two of them are actively
>> developed.  The people working on several of these subprojects drifted
>> away and no one noticed because it wasn't important to the remaining
>> people.   Most of those who remain are, rightly so, not willing to
>> devote volunteer time to something they have little-to-no involvement
>> with.  The other PMC members will still do it grudgingly but as a
>> burden.   Even "retiring" these subprojects is not possible because no
>> one is willing to spend the time to make that happen.
>> 
>> To recap, my recommendations to the PMC of an umbrella project would be:
>> 
>> - Require subproject reports.   Have them due two weeks before the TLP
>> board report is due.   Merge them into the TLP board report.   Use
>> similar criteria to determine subproject health.  The PMC becomes "the
>> board" within their domain.
>> 
>> - Split subprojects off to TLPs immediately as soon as a sustainable
>> community develops.  This might be before code exists.
>> 
>> - Have a plan beforehand on when and how you are going to "retire"
>> subprojects which are no longer maintained.  You are going to need
>> your own attic concept.
>> 
> 

Apache EU Roadshow CFP Closing Soon (23 February)

[Sharan F]

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development

Re: [RESULT] Accept Code donations: Sheldon and Chatterbox

[Jean-Louis Monteiro]

John,

What would be your advice for creating the git repos?
Usual Git in US or gitbox?

Jean-Louis

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 1:01 PM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> I knew there was something.
> Thanks for the gitbox info
>
> Le 13 févr. 2018 12:26, "John D. Ament"  a écrit :
>
>
>
> On 2018/02/13 09:29:37, Romain Manni-Bucau  wrote:
> > side note: we don't need to go through asf@incubator here, the vote
> passed
> > and the project can be imported as soon as the repos are created by
> infra.
> > The only thing to take care (and a lot) is to make clear tomitribe gives
> > (donates) this code to asf. A public message on a list is generally good
> > and a commit done by a tomitribe member are enough in general.
>
> All code donations need to have IP Clearances filed & voted upon.  So yes,
> there's something you need to do in the Incubator.
>
> >
> > In other words: let just that happen :)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> >  high-performance>
> >
> > 2018-02-13 10:27 GMT+01:00 Thiago Veronezi :
> >
> > > Yes, looking at the steps now. I will ping you later for more
> guidance. At
> > > first glance, It looks like a very complex process. It's a good
> learning
> > > opportunity.
> > > Thanks man.
> > >
> > > []s,
> > > Thiago
> > >
> > >
> > > On Tue, Feb 13, 2018 at 7:15 AM, Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > >
> > > > I'll create the tickets for infra so we have the repos ready.
> > > >
> > > > Can you look at the other steps?
> > > > I'm not very familiar with the steps in case of code donation. So
> I'll
> > > need
> > > > to document myself as well.
> > > >
> > > > Le 13 févr. 2018 10:10, "Thiago Veronezi"  a
> écrit
> > > :
> > > >
> > > > > Awesome!
> > > > >
> > > > > Thanks guys.
> > > > >
> > > > > Thanks Jean-Louis for sort this out that fast! Count me in for the
> > > > > incubator work.
> > > > >
> > > > > []s,
> > > > > Thiago.
> > > > >
> > > > >
> > > > > On Tue, Feb 13, 2018 at 7:08 AM, Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com> wrote:
> > > > >
> > > > > > Hey Thiago.
> > > > > >
> > > > > > I have done all the change and prepared the donation. It needs
> some
> > > > > > paperwork for IP clearance.
> > > > > >
> > > > > > I have followed the option where we have each in its own repo
> instead
> > > > of
> > > > > > the current TomEE repo. It appeared to be more flexible to me bit
> > > happy
> > > > > to
> > > > > > change if the community thinks it's better.
> > > > > >
> > > > > > If you can help with incubator and paperwork I have the 2
> projects
> > > > ready
> > > > > > for review.
> > > > > >
> > > > > > Le 13 févr. 2018 10:00, "Thiago Veronezi" 
> a
> > > > écrit
> > > > > :
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > I have some use for Chatterbox and I would like to contribute.
> > > > > > >
> > > > > > > Sheldon and Chatterbox are examples of awesome use of stack
> Java EE
> > > > > JCA,
> > > > > > > aren't they?
> > > > > > >
> > > > > > > What about creating a module "resource-adapters" and having
> these
> > > > guys
> > > > > > > there?
> > > > > > >
> > > > > > > com.apache.tomee.rars
> > > > > > > chatterbox
> > > > > > >
> > > > > > > com.apache.tomee.rars
> > > > > > > sheldon
> > > > > > >
> > > > > > > We would have them available for download on tomee.apache.org
> and
> > > > > maven
> > > > > > > central without going through yet another project
> configuration.
> > > > > > >
> > > > > > > If these guys grow so much that they require to be split into
> their
> > > > own
> > > > > > top
> > > > > > > project, we can do that later.
> > > > > > >
> > > > > > > []s,
> > > > > > > Thiago.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Feb 6, 2018 at 3:15 PM, Mark Struberg
> > > > >  > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 for a new github repo and 1 per project.
> > > > > > > > And we still need a name for this 'aggregator'.
> > > > > > > > In Myfaces it was myfaces-ext-*But if you did your history
> > > lections
> > > > > > then
> > > > > > > > you would have noticed that keeping myfaces in the name was
> NOT a
> > > > > good
> > > > > > > > idea.While CODI (myfaces-ext-cdi) did also run perfectly
> fine on
> > > > > > Mojarra
> > > > > > > we
> > > > > > > > had a really huge acceptance problem. This later lead us to
> join
> > > > > forces
> > > > > > > > with Seam and merge together to Apache DeltaSpike - just to
> > > remove
> > > > > any
> > > > > > > > doubt that it will only run with MyFaces.
> > > > > > > > N