Re: [VOTE] Explore creating a reusable JWT Library

[Rudy De Busscher]

>
> Primarily what I'd like to do is really nail the public key format
> manipulation.  I did a huge amount of research in this and would like to
> come up with an extremely well tested library that can natively read all
> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line tools
> for converting between them.


That would be super awesome. I have been working on the same thing the past
month or so.

Rudy

On 2 May 2018 at 00:13, David Blevins  wrote:

> Requested a repo we could potentially use for this.
>
> Primarily what I'd like to do is really nail the public key format
> manipulation.  I did a huge amount of research in this and would like to
> come up with an extremely well tested library that can natively read all
> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line tools
> for converting between them.
>
> This could be useful to both the TomEE and Geronimo MicroProfile JWT impls.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > The code still is in a PR (#123) for the moment
> >
> > I'm in to help.
> > Still some small fixes to do and I'd like MP-Config to be used to
> configure
> > keys, issues, and others.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg  >
> > wrote:
> >
> >> As noted elsewhere: the vote question was a mixture of 'what do you
> >> think' (consensus -> majority vote)  and 'is it ok' (technical ->
> unanimous
> >> vote).
> >> I'd also be in favour to do the generic parts in Geronimo and only do
> the
> >> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If
> this
> >> is interpreted as commit vote then I vote -0
> >> The work is the same and as long as it's been done I'm fine either ways.
> >> Now that we did all the 3 weeks of rambling and discussions let's focus
> on
> >> the important stuff.
> >> Where is the code? Who did already work on it? Or do we again have 30
> >> people discussing but just 2 working? ;)
> >>
> >> LieGrue,strub
> >>On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
> >> david.blev...@gmail.com> wrote:
> >>
> >>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau  >
> >> wrote:
> >>>
> >>> It was more as a "if im always the only one seeing tomee differently i
> >> can
> >>> leave to let you space". Not as a threat.
> >>
> >> That's a generous sentiment.  Either way the best outcome is that you
> stay
> >> and we all learn the lesson that disagreeing is ok and healthy.  How is
> the
> >> most important part.
> >>
> >> Disagreement can be an incredibly productive and innovative thing if
> done
> >> right.  By definition, that means this project is sitting on some
> >> incredible innovative potential.
> >>
> >> A concrete way I think we can measure ourselves is by the number of
> people
> >> who feel comfortable voting.  I would consider a vote of 20 people that
> >> included 3 -1 votes to be significantly more healthy than a vote of 3
> >> people and all +1s.
> >>
> >>> [...]
> >>> There is no veto at apache if you check rules closely. All is more
> about
> >>> respect and overall consensus IIRC.
> >>
> >> I want to be careful that we don't learn a false lesson as Apache does
> >> have technical vetos.  These are more meant for line-of-code level
> input vs
> >> community direction.
> >>
> >> The intention of the two votes was to make the line a little more clear.
> >>
> >> - The first vote "Merge Pull Request 123 - MicroProfile JWT support" was
> >> intended to flush out line-of-code level technical issues with the PR:
> >> breaks the build; doesn't follow code style; introduces security issues.
> >> It's ultimately a Review-than-Commit vote and a -1 should be viewed as a
> >> technical veto.
> >>
> >> - The second vote "Explore creating a reusable JWT Library" was intended
> >> to determine overall desire on what the next step should be.  No commit
> >> being reviewed, more of a community level discussion.  A -1 should not
> be
> >> viewed as a veto.
> >>
> >>
> >> -David
> >>
> >>
>
>

Re: MP.next()

[Rudy De Busscher]

If needed, I can lend a hand in updating TomEE 7.1

But I agree, certification becomes less an issue.I have the impression
that  even Big vendors don't set it as a priority.

Rudy

On 19 April 2018 at 11:24, Mark Struberg  wrote:

> Of course having a TomEE-7.1 which bumps the requirement to java8 is cool.
> And I fully support that.
> But right now let's please focus on shipping TomEE-7.0.5 first.
> Most probably 7.1 could be done almost in parallel.
> But we do not have endless resources. At least I don't.
>
> LieGrue,
> strub
>
> > Am 19.04.2018 um 05:25 schrieb David Blevins :
> >
> >
> >> On Apr 18, 2018, at 4:08 AM, Mark Struberg 
> wrote:
> >>
> >> There was a discussion about this a few weeks ago where we agreed to
> ship TomEE-7.0.5 and only then switch to a branch.
> >>
> >> That's the reason why we backported tons of stuff in Johnzon, OWB and
> OpenJPA.
> >> Just waiting for feedback whether it now works fine or if there is
> still something broken.
> >>
> >> So my suggestion is to apply this to the TomEE8 branch and wait with
> the other PR until TomEE-7.0.5 is released.
> >
> > Kicked off a proper "Status of TomEE 8" thread so we can have a full
> conversation on what to do with TomEE 8.
> >
> > If people were willing to put the effort into a TomEE 7.1 in addition to
> whatever is decided in that thread, would you be ok with a TomEE 7.1 as
> well?
> >
> > For context: I know Jean-Louis is heading off to Brazil in May to do a
> TomEE talk that shows his JWT work.  Ideally he's not showing a snapshot
> and people could leave with something they can try.  He's doing that talk
> again in June.
> >
> > My personal perspective is if the decision was made to release TomEE 8
> now, I'd still see value in a 7.1 release with MicroProfile as then the
> users would have the choice.  Some may not want to do a Java EE 7 to Java
> EE 8 upgrade, but still want to enjoy some MicroProfile technologies.
> >
> >
> > -David
> >
> >
> >
>
>

Re: MP.next()

[Rudy De Busscher]

+1 (Non binding)

Rudy

On 17 April 2018 at 13:12, Roberto Cortez 
wrote:

>
> +1On Tuesday, April 17, 2018, 12:11:58 AM GMT+1, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
>  Hi community,
>
> Most microprofile requires Java 8.
> Is everyone ok if we have microprofile implemented on TomEE 7.1 (Java 8)?
>
> Thanks
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>

Re: [RESULT] Explore creating a reusable JWT Library

[Rudy De Busscher]

Sorry Romain but I still have doubts if the code is really reusable, like
that you can just add it to WildFly or Payara and that it works. (like
Geronimo Config for example)

Things like integrating with @RolesAllowed is not standardized (except
using JASPIC maybe which I tried but I had other issues)

More generic parts like injecting the Claims etc, that could work.

But I'm fine that the code is maintained at Geronimo, that TomEE code only
contains the integration parts. But it will not be a complete
implementation of MP JWT Auth (The Geronimo project).

Rudy

On 10 April 2018 at 06:58, Romain Manni-Bucau  wrote:

> Le 10 avr. 2018 05:23, "David Blevins"  a écrit :
>
> Officially closing the vote.  Thanks for the patience everyone.  As
> mentioned in the other vote, this one needed some good discussion and a bit
> of extra time.
>
> +1s
> Andy Gumbrecht
> David Blevins
> Ivan Junckes Filho
> Jean-Louis Monteiro
> Jonathan Gallimore
> Thiago Veronezi
>
> +0
> Rudy De Busscher
>
> -1s
> Mark Struberg
> Romain Manni-Bucau
>
> This was intended as a non-technical vote, so I've registered Mark's -1 as
> he intended it.  Thanks, Mark, for the clarification.  Matthew, you didn't
> vote, your participation was quite high -- thank you!  You're more then
> welcome to vote, sir :)
>
> This was a consensus vote to see if there was will keep working on the JWT
> code here and see if it could be made reusable.  We didn't really need this
> vote to accomplish anything other than to see where people's heads are at
> and make sure we're communicating with each other clearly.
>
> It does seem over all that the desire is to take a couple more steps.  This
> vote did not address where the code should live in its final state.  We
> don't really know how reusable anything will be.
>
>
>
> ...it has been mention 3 times the code IS reusable and should just be a
> lib. It was codes this exact way so no ambiguity here.
>
>
> I'd probably expect us to take a few more steps, see how things look and
> come back to the "where" topic.
>
>
> -David
>
>
> > On Mar 18, 2018, at 5:02 PM, David Blevins 
> wrote:
> >
> > The vote for merging PR 123 does not address community will on what to do
> with the code beyond merging it.  One can realistically vote +1 to merge
> the code, but then desire to see the code cleaned up and moved elsewhere.
> One can realistically desire seeing an attempt to clean up the code to find
> what is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
> >
> > Out of respect for people who may not know exactly how they feel (TomEE
> or Geronimo), this is a vote for the latter.
> >
> > Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
> >
> > +1 Let's give it a shot here
> > +-0
> > -1 Let's do this elsewhere
> >
> > If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is not
> being voted on.  People are welcome to decide differently based on the
> results of the exercise.
> >
> >
> > -David
> >
>

Re: [VOTE] Explore creating a reusable JWT Library

[Rudy De Busscher]

+0

If it needs to be reusable it should also work with other Application
Servers (which I don't believe is possible with MP JWT Auth).

So First within TomEE and then try it to extract it and make it work
elsewhere also.

Rudy

On 29 March 2018 at 20:21, Ivan Junckes Filho  wrote:

> I think we should keep the code in TomEE.
>
> +1
>
> On Thu, Mar 29, 2018 at 3:16 PM, Thiago Veronezi 
> wrote:
>
> > +1 Let's give it a shot here
> >
> > On Thu, Mar 29, 2018 at 2:12 PM, David Blevins 
> > wrote:
> >
> > > I'd like to wrap this up so if you have other questions or would like
> to
> > > vote, now is the time.  Reminder, you do not need to be a committer to
> > vote.
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On Mar 18, 2018, at 5:02 PM, David Blevins 
> > > wrote:
> > > >
> > > > The vote for merging PR 123 does not address community will on what
> to
> > > do with the code beyond merging it.  One can realistically vote +1 to
> > merge
> > > the code, but then desire to see the code cleaned up and moved
> elsewhere.
> > > One can realistically desire seeing an attempt to clean up the code to
> > find
> > > what is reusable and may wish to withhold a final decision until we see
> > how
> > > fruitful such a module would be.
> > > >
> > > > Out of respect for people who may not know exactly how they feel
> (TomEE
> > > or Geronimo), this is a vote for the latter.
> > > >
> > > > Vote: Should we attempt to extract code from the JWT PR to see what
> is
> > > reusable and how successful such a jar would be?
> > > >
> > > > +1 Let's give it a shot here
> > > > +-0
> > > > -1 Let's do this elsewhere
> > > >
> > > > If the vote is +1 to attempt an extraction of reusable code here,
> final
> > > conclusion of if that extraction is worth it or where it should live is
> > not
> > > being voted on.  People are welcome to decide differently based on the
> > > results of the exercise.
> > > >
> > > >
> > > > -David
> > > >
> > >
> > >
> >
>

Re: [VOTE] Merge Pull Request 123 - MicroProfile JWT support

[Rudy De Busscher]

+1 To merge into TomEE

Rudy

On 29 March 2018 at 20:19, Ivan Junckes Filho  wrote:

> Cool, I didn't know I could vote as a contributor.
>
> I am +1 on this PR to be merged on TomEE.
>
> On Thu, Mar 29, 2018 at 3:14 PM, Bruno Baptista 
> wrote:
>
> > +1 on merge
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> >
> > On 29-03-2018 19:13, Otávio Gonçalves de Santana wrote:
> >
> >> + 1, Let's merge and move it forward.
> >>
> >> On Thu, Mar 29, 2018 at 3:12 PM, Bruno Baptista 
> >> wrote:
> >>
> >> + 1, Let's merge.
> >>>
> >>> If later someone wants to move it elsewhere in the future, that's fine.
> >>>
> >>> While people figure out how to do that, at least we will have something
> >>> working for the users.
> >>>
> >>> Cheers
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>>
> >>> On 19-03-2018 00:02, David Blevins wrote:
> >>>
> >>> Jean-Louis has put a PR up for discussion for JWT Support in TomEE.
> 
> - https://github.com/apache/tomee/pull/123
> 
>  There are 35 commits spanning 27 days of work.  It's been reviewed by
>  Andy and Rudy.  One a committer and one a contributor, which is great
>  for
>  us.
> 
>  There's an open question as to where the code should live in its final
>  state: TomEE or Geronimo.  This conversation doesn't seem conclusive
>  after
>  12 days.  It's ok for us not to agree, but we should have more votes
> so
>  there is a clear outcome and we are acting as a community to our best
>  ability.
> 
>  Vote: Merge Pull Request 123?
> 
> +1  Yes, let's do it
> +-0 Abstain
> -1  No, don't put this code in TomEE
> 
> 
>  Out of respect for the conversation, this is not a vote of where the
>  code
>  will live in its final state.  This is just a decision to merge or
>  not.  It
>  would give the users something they can try, which can be updated by a
>  future PR if the code does eventually move.
> 
> 
>  -David
> 
> 
> 
> >
>

Re: MP-JWT progress

[Rudy De Busscher]

OK (non-binding of course :) for generic classes at Geronimo.

On 12 March 2018 at 16:01, Jean-Louis Monteiro 
wrote:

> So what's the conclusion here?
>
> Should I request a git repo on geronimo and extract all generic classes
> there along side with other implementations?
> Or do you guys prefer another tomee repo with the MP-JWT impl?
>
> I don't mind if they go here and there, just need to know so I can move on
> with the contribution.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Mar 9, 2018 at 2:15 PM, Romain Manni-Bucau 
> wrote:
>
> > 2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Currently this in a PR, so it hasn't actually been merged anywhere.
> > There's
> > > some at least some TomEE specific code, so some modules need defining
> > > before it can be "moved" in my view.
> > >
> > > Rudy's point is good one - no doubt a generic, reusable module may well
> > be
> > > what we end up with. Wherever that lives when it has clearly been
> > defined,
> > > it needs documenting and showing how to use it.
> > >
> > > We talked previously about being able to have modules in separate repos
> > > under TomEE. Is there some issue with doing that? What's the rush to
> > shift
> > > this off to Geronimo?
> > >
> >
> > No rush, geronimo will have a jwt-auth impl and I was waiting JL push
> what
> > he did before speaking of creating a project @G. I would like to share
> the
> > same impl with tomee to avoid to x2 the effort. however if not desired it
> > is fine as well.
> >
> > It is also important to keep in mind that on tomee side there is *no*
> > specific code, only fixes in the propagation which also impact
> webprofile,
> > nothing linked to MP or this particular spec.
> >
> >
> >
> > >
> > > Jon
> > >
> > > On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <
> rdebussc...@gmail.com
> > >
> > > wrote:
> > >
> > > > I'm not saying we should move TomEE code into Geronimo.
> > > >
> > > > If we move the generic stuff for JWT Auth to Geronimo, it will not be
> > > > enough to have it completely functional. And that should be made
> clear
> > > from
> > > > the beginning for all potential usages.
> > > >
> > > > On 9 March 2018 at 12:20, John D. Ament 
> wrote:
> > > >
> > > > > I don't think its a good idea to move TomEE code into Geronimo.
> > > > >
> > > > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > If there is no other comment, any objection to move it to
> > > > > > geronimo-jwt-auth? (let say if not we do it on monday european
> > time)
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github
> > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <https://www.packtpub.com/application-development/java-
> > > > > ee-8-high-performance>
> > > > > >
> > > > > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > > > >
> > > > > >>
> > > > > >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com>
> > > > > >> :
> > > > > >>
> > > > > >>> Hi community,
> > > > > >>>
> > > > > >>>
> > > > > >>> So we now have something close in terms of MP-JWT
> implementation.
> > > > > >>>
> > > > > >>> With the playground branch I've been working on (Thanks Romain
> > for
> > > > the
> > > > > >>> help), we now pass 100% of the TCK (including a missing part in
> > > > MP-JWT
> > > > > >>> TCK
> > > > > >>> I have eagerly added - see ticket on MP-JWT).
> > > > > >>>
> > > > > >>> Now the question is how do we proceed?
> > > > > >>> Knowing that most of the code is not TomEE specific.
> > > > > >>>
> > > > > >>
> > > > > >> I'd move it to G to a new git repo keeping only the tck exec - a
> > bit
> > > > > like
> > > > > >> Roberto started with config. I'll be happy to help fixing the
> > small
> > > > > >> remaining enhancements to do (jwt parsing based on jsonb/p,
> config
> > > > etc).
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> Only few things are in the TomcatSecurityService but that can
> > > remain
> > > > in
> > > > > >>> TomEE because it's not really MP-JWT specific either.
> > > > > >>>
> > > > > >>
> > > > > >> +1, was overdue anyway for our servlet-ejb integration
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> Here is the PR for discussion
> > > > > >>> https://github.com/apache/tomee/pull/123
> > > > > >>>
> > > > > >>> Cheers
> > > > > >>> Jean-Louis
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Jean-Louis Monteiro
> > > > > >>> http://twitter.com/jlouismonteiro
> > > > > >>> http://www.tomitribe.com
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: MP-JWT progress

[Rudy De Busscher]

I'm not saying we should move TomEE code into Geronimo.

If we move the generic stuff for JWT Auth to Geronimo, it will not be
enough to have it completely functional. And that should be made clear from
the beginning for all potential usages.

On 9 March 2018 at 12:20, John D. Ament  wrote:

> I don't think its a good idea to move TomEE code into Geronimo.
>
> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
> wrote:
>
> > If there is no other comment, any objection to move it to
> > geronimo-jwt-auth? (let say if not we do it on monday european time)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> >  ee-8-high-performance>
> >
> > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
> >
> >>
> >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> >> :
> >>
> >>> Hi community,
> >>>
> >>>
> >>> So we now have something close in terms of MP-JWT implementation.
> >>>
> >>> With the playground branch I've been working on (Thanks Romain for the
> >>> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> >>> TCK
> >>> I have eagerly added - see ticket on MP-JWT).
> >>>
> >>> Now the question is how do we proceed?
> >>> Knowing that most of the code is not TomEE specific.
> >>>
> >>
> >> I'd move it to G to a new git repo keeping only the tck exec - a bit
> like
> >> Roberto started with config. I'll be happy to help fixing the small
> >> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
> >>
> >>
> >>>
> >>> Only few things are in the TomcatSecurityService but that can remain in
> >>> TomEE because it's not really MP-JWT specific either.
> >>>
> >>
> >> +1, was overdue anyway for our servlet-ejb integration
> >>
> >>
> >>>
> >>> Here is the PR for discussion
> >>> https://github.com/apache/tomee/pull/123
> >>>
> >>> Cheers
> >>> Jean-Louis
> >>>
> >>>
> >>> --
> >>> Jean-Louis Monteiro
> >>> http://twitter.com/jlouismonteiro
> >>> http://www.tomitribe.com
> >>>
> >>
> >>
> >
>

Re: MP-JWT progress

[Rudy De Busscher]

for example
JAX-RS application class annotated with @LoginConfig. > only urls defined
in the @ApplicationPath should use the JWT Auth method.

Other endpoints, like servlet should use the 'default' method defined in
the web.xml.

AFAIK, there exist no integration point possible to do this, not even
JASPIC. So it needs to be solved by the 'internals' of the Application
server.



On 9 March 2018 at 12:04, Romain Manni-Bucau  wrote:

> 2018-03-09 12:02 GMT+01:00 Rudy De Busscher :
>
> > No objection but an important remark to make.
> >
> > it will not be enough to just add this  geronimo-jwt-auth artifact to a
> > server to have it functional. There will be some server-side integration
> > code required (just as we will need for TomEE)
> >
>
> it is not the case for tomee and shouldn't normally if the server
> propagates properly its security context. It is not always the case, you
> are right,
> but for asf servers it should AFAIK, no?
>
>
> >
> > This is thus clearly different from other microprofile implementations
> like
> > geronimo-config.
> >
> > Just want to mention this as there are already people (outside of this
> > community) thinking that such a thing is possible (or should be possible)
> >
> > Rudy
> >
> > On 9 March 2018 at 11:49, Romain Manni-Bucau 
> > wrote:
> >
> > > If there is no other comment, any objection to move it to
> > > geronimo-jwt-auth? (let say if not we do it on monday european time)
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <https://www.packtpub.com/application-development/java-
> > > ee-8-high-performance>
> > >
> > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
> > >
> > > >
> > > > 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com
> > > >:
> > > >
> > > >> Hi community,
> > > >>
> > > >>
> > > >> So we now have something close in terms of MP-JWT implementation.
> > > >>
> > > >> With the playground branch I've been working on (Thanks Romain for
> the
> > > >> help), we now pass 100% of the TCK (including a missing part in
> MP-JWT
> > > TCK
> > > >> I have eagerly added - see ticket on MP-JWT).
> > > >>
> > > >> Now the question is how do we proceed?
> > > >> Knowing that most of the code is not TomEE specific.
> > > >>
> > > >
> > > > I'd move it to G to a new git repo keeping only the tck exec - a bit
> > like
> > > > Roberto started with config. I'll be happy to help fixing the small
> > > > remaining enhancements to do (jwt parsing based on jsonb/p, config
> > etc).
> > > >
> > > >
> > > >>
> > > >> Only few things are in the TomcatSecurityService but that can remain
> > in
> > > >> TomEE because it's not really MP-JWT specific either.
> > > >>
> > > >
> > > > +1, was overdue anyway for our servlet-ejb integration
> > > >
> > > >
> > > >>
> > > >> Here is the PR for discussion
> > > >> https://github.com/apache/tomee/pull/123
> > > >>
> > > >> Cheers
> > > >> Jean-Louis
> > > >>
> > > >>
> > > >> --
> > > >> Jean-Louis Monteiro
> > > >> http://twitter.com/jlouismonteiro
> > > >> http://www.tomitribe.com
> > > >>
> > > >
> > > >
> > >
> >
>

Re: MP-JWT progress

[Rudy De Busscher]

No objection but an important remark to make.

it will not be enough to just add this  geronimo-jwt-auth artifact to a
server to have it functional. There will be some server-side integration
code required (just as we will need for TomEE)

This is thus clearly different from other microprofile implementations like
geronimo-config.

Just want to mention this as there are already people (outside of this
community) thinking that such a thing is possible (or should be possible)

Rudy

On 9 March 2018 at 11:49, Romain Manni-Bucau  wrote:

> If there is no other comment, any objection to move it to
> geronimo-jwt-auth? (let say if not we do it on monday european time)
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
>
> >
> > 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro  >:
> >
> >> Hi community,
> >>
> >>
> >> So we now have something close in terms of MP-JWT implementation.
> >>
> >> With the playground branch I've been working on (Thanks Romain for the
> >> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> TCK
> >> I have eagerly added - see ticket on MP-JWT).
> >>
> >> Now the question is how do we proceed?
> >> Knowing that most of the code is not TomEE specific.
> >>
> >
> > I'd move it to G to a new git repo keeping only the tck exec - a bit like
> > Roberto started with config. I'll be happy to help fixing the small
> > remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
> >
> >
> >>
> >> Only few things are in the TomcatSecurityService but that can remain in
> >> TomEE because it's not really MP-JWT specific either.
> >>
> >
> > +1, was overdue anyway for our servlet-ejb integration
> >
> >
> >>
> >> Here is the PR for discussion
> >> https://github.com/apache/tomee/pull/123
> >>
> >> Cheers
> >> Jean-Louis
> >>
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
> >
> >
>

Re: Implementing Microprofile JWT

[Rudy De Busscher]

>
> Can we assume Java8 for this attempt?
> Oh and more important: Will the integration work based on TomEE7 (would
> require Java7) or the upcoming TomEE8?
> I'd say we should focus on TomEE8 and Java8


MicroProfile specs are defined in Java 8, so TomEE8 seems the only option.

regards
Rudy


On 15 February 2018 at 09:37, Mark Struberg 
wrote:

>
>
> > Am 15.02.2018 um 07:50 schrieb 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.
>
>
> No, there is no meta discussion. This is about reusability in other
> projects. As clearly stated as that.
> I think we can easily get this done by splitting it in a core part and
> then a second part which exposes the JsonWebToken as Principal in various
> EE apis. The overall structure will become way cleaner imo as it would be
> highly modular without adding too much overhead.
>
> >
> > I'd probably lean towards getting a prototype done with the mutual
> > understanding this part of the discussion is still open.
>
> +1
>
> > Once we have code
> > in hand, we can have a more informed discussion and circle back to reuse.
>
> -1 You have to design with reuse in mind.
> I'm not talking about making it overcomplicated and unecessarily modular,
> but just address the things we know already.
>
> >
> >> 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.
>
> Thanks for pointing me to this.
> 'integration points'. Even the spec indicates that the EE part is merely
> integration work.
> That might be a lot of work of course. But it would be cool if getting the
> JsonWebToken would merely be one line of code which is in the mp-jwt-core
> package.
>
> >
> > 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.
>
> Oki, I will start a discussion over at MicroProfile.
> Thinking about a JsonWebTokenBuilder or something.
>
> >
> > 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.
>
> JWT doesn't even require oauth2, isn't?
> Of course oauth2 _could_ be the payload. But that's no necessity for
> everyone.
> Most users will not need that actually. But they might be more interested
> in having a radius like single sign on via JWT.
> At least that's what I hear from my customers.
>
> >
> >
> >> * 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 complexi

Re: Implementing Microprofile JWT

[Rudy De Busscher]

t; >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 2018/02/12 20:42:58, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> >>>>> rmannibu...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> No Andy, as mentionned in the discussion Geronimo hosts the
> >>>>> microprofile
> >>>>>>> @asf. This is why jwt should probably be done in geronimo which is
> >>>> the
> >>>>> asf
> >>>>>>> ee related project umbrella.
> >>>>>>>
> >>>>>>
> >>>>>> I don't recall that discussion. Where did it take place?
> >>>>>
> >>>>> I *think* he meant me.  The only time JWT came up on Geronimo was at
> >> [1].
> >>>>> I had mentioned bringing over an impl based on Jose4J, Romain felt
> very
> >>>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why
> that
> >>>> is,
> >>>>> but it seemed based on the discussion we had two different aims so it
> >>>>> wasn't something I pushed forward on.  If there's interest within
> TomEE
> >>>> to
> >>>>> get a JWT impl up and running, I'd be happy to help (though I do feel
> >>>>> strongly relying on a 3rd party lib for the actual signature
> >> validation +
> >>>>> external sig support is important; to avoid that overhead).
> >>>>>
> >>>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast
> rules
> >>>>> about what projects are allowed to host.  For example, there's
> interest
> >>>>> within Skywalking to host the CDI and JAX-RS extensions to support
> >>>> OpenApi;
> >>>>> but this spec doesn't represent something any server vendor would
> >> support
> >>>>> since its really about your APM solution.  CXF happily took on the MP
> >>>> Rest
> >>>>> Client when I proposed it; though I would hope TomEE relies on the
> CXF
> >>>>> library instead of crafting their own client (selfish desires).  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.
> >>>>>
> >>>>> 
> >>>>>
> >>>>> John
> >>>>>
> >>>>> [1]: https://lists.apache.org/thread.html/
> >> 4edc997cfe2e45aaf25bb118bc6216
> >>>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I understand it is not the most convenient for tomitribe which
> >>>> probably
> >>>>>>> perfers to own the full project(s) but as a foundation member I d
> >>>>> really
> >>>>>>> like to not let company details pollute projects
> >>>>>>
> >>>>>>
> >>>>>>> Also the discussion made clear to not do it in current repo
> whatever
> >>>>>>> project is used as umbrella so we should revert that and finish the
> >>>>>>> discussion before any action to not kill tomee project by a hard
> >>>>> company
> >>>>>>> driven management making it no more in the OSS spirit.
> >>>>>>>
> >>>>>>
> >>>>>> I agree the discussion should happen first, and I note that the
> change
> >>>>> has
> >>>>>> been reverted. I recall that we agreed on this list that we'd create
> >>>> new
> >>>>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
> >>>> Should
> >>>>>> other components sit under TomEE, I imagine that they would follow
> the
> >>>>> same
> >>>>>> pattern - i.e. discuss first, agree location, create repo or 

Re: Implementing Microprofile JWT

[Rudy De Busscher]

I think it is a very important spec, also for non-microprofile
implementations as it can enhance the interoperability of all servers.

I'm also very interested in the implementation (and want to help a bit with
it also :) )

regards
Rudy



On 2 February 2018 at 11:23, Mark Struberg 
wrote:

> To clarify this even further:
> The Geronimo Server is now officially dead.
> But the Geronimo project is not. It alredy contains quite a few modular
> parts which are reused in many ASF projects and also outside.
> Examples is the geronimo-transaction-manager, geronimo-javamail,
> geronimo-config, xbean-finder, etc
>
> Of course it would probably make sense to fold those 2 projects together,
> as already discussed in the past.
> I'm still all open to it, but I have an important criterium to fulfil:
> If we move those portable parts to TomEE, then this would mean that TomEE
> would become an 'Umbrella project'.
> And further that we would need a new name for those portable parts.
> They would effectively be mainatained by the TomEE community (which has a
> big overlap with Geronimo anyway) but those parts must clearly be
> recognized separately from TomEE.
>
> Otherwise people will assume that those parts only work within TomEE -
> where in reality they would even work on WildFly or Liberty, etc. or even a
> naked Tomcat.
> Got me?
>
> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>
> LieGrue,
> strub
>
> PS: I'd also love to keep the org.apache.geronimo package name to ease
> backward compatibility.
>
>
> > Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau  >:
> >
> > 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > osant...@tomitribe.com>:
> >
> >> Guys, I have a question:
> >>
> >> Why not a project to each implementation?
> >>
> >
> > this is the case but geronimo is used as an umbrella project.
> >
> >
> >> This way I can use just a specific if I want also.
> >>
> >
> > exactly the goal and user usage AFAIK ;)
> >
> > long story short: we learnt from the past errors and since always the
> same
> > people work on these projects it is better to not split it accross N
> > communities since
> > it leads to a lot of efforts for these people. Having a single umbrella
> > project with N subprojects reduces the administrative work etc and
> enhance
> > the projects productivity.
> >
> >
> >> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Hi JL,
> >>>
> >>> Microprofile apache effort is hosted in geronimo and John already spoke
> >>> about it I think. Would probably saner to keep it all at the same place
> >> for
> >>> the foundation.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github  >>> rmannibucau> |
> >>> LinkedIn  | Book
> >>>  >>> ee-8-high-performance>
> >>>
> >>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> jlmonte...@tomitribe.com
> >>> :
> >>>
>  Hi all,
> 
>  I was wondering if we could have the Microprofile JWT implemented in
> >>> TomEE.
>  What do you think?
> 
>  I was reading the spec and I'd like to contribute that in.
> 
>  Jean-Louis
> 
>  --
>  Jean-Louis Monteiro
>  http://twitter.com/jlouismonteiro
>  http://www.tomitribe.com
> 
> >>>
> >>
>
>

Re: The EE8 Roadmap

[Rudy De Busscher]

Great news

What are the plans for the Security API?  It will also be included in the
Web Profile.

I can help with the implementation if you like.

Best regards
Rudy


On 17 June 2017 at 21:57, Mark Struberg  wrote:

> FYI, With help from Romain, Reinhard Sandtner, Gerhard Petracek and John
> Ament,  Apache OpenWebBeans now passes the CDI-2.0 TCK!
>
> The next step is to do a bit more testing, release the missing Geronimo
> spec APIs and then we are good to go for rolling TomEE-8.0.0 ^^
>
> LieGrue,
> strub
>
>
>
> > Am 05.06.2017 um 12:59 schrieb Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>:
> >
> > Wow, great status Mark.
> > Thanks a lot.
> >
> > Yes, agree, TomEE 8.x seems to be the de facto choice based on what the
> > community decided last time.
> > Even though the time is missing I'd like to help somehow and join the
> > effort.
> >
> > I'll shoot when I have some time.
> >
> > Cheers.
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Fri, Jun 2, 2017 at 8:55 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> 2017-06-02 20:27 GMT+02:00 Mark Struberg :
> >>
> >>> Hi folks!
> >>>
> >>> Behind the scene there was a lot of work done towards EE8.
> >>> Not directly in TomEE, but in most parts which are needed
> >>>
> >>> * Tomcat 9 for Servlet 4.0 - While the final API is not yet ready we
> >>> already have many public Milestone builds
> >>>
> >>> * OpenWebBeans-2.0.x for CDI 2.0 - We already implemented most of the
> new
> >>> features and are down to 35 failing TCK tests (out of 1300). Might take
> >> us
> >>> 2 more weeks to finish, but we are already very close
> >>>
> >>> * BVal - Matt Benson is working like wild for implementing the new spec
> >>> changes. Once OWB is finished Romain and I will join the effort with
> more
> >>> power. Others are welcome to help of course!
> >>>
> >>> * Johnzon for JSON-P 1.1 and JSON-B 1.0: 1.1.1 is currently being
> >>> released. Works like a charm!
> >>>
> >>> * MyFaces - gonna need to check the latest status, but I think Leo has
> >>> already implemented most things
> >>>
> >>> * OpenJPA - lags a bit behind, but there have been no changes so far in
> >>> JPA for EE8 anyway
> >>>
> >>> * Geronimo - we have quite a few new spec versions to be released. Most
> >>> are already implemented and just need to get released once the specs go
> >>> final and we can compare our signatures with the ones from the official
> >>> artifacts.
> >>>
> >>>
> >>> How to name the baby? TomEE-8.0.0 seems quite natural to me, wdyt?
> >>>
> >>>
> >> Well no real choice we moved to 7 recently with this engagement for at
> >> least a moment.
> >>
> >>
> >>> When to branch away from trunk?
> >>>
> >>
> >> When at least OWB is fully ready I'd say and 7.0.4 out, can do it soon
> if
> >> it helps
> >>
> >>
> >>> After OWB is finished?
> >>>
> >>>
> >> Hehe seems we agree ;)
> >>
> >>
> >>> C'mon, tell me what you think, lords and ladies!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>
>
>

Java EE Security API implementation plans for TomEE 8?

[Rudy De Busscher]

Hi All,

I'm working as individual on the Expert Group of the Java EE Security API
(JSR-375).

And I was wondering what the plans are within TomEE or Apache to make an
implementation of this specification? As this will be required when TomEE
will be Java EE 8 compliant I guess.

And if I can help in any way? (as I'm also an Apache committer on various
projects)

Thanks

Best regards
Rudy De Busscher