Date   

Re: Final Approval Ballot passes! :)

Werner Keil
 

Wherever that might be, but especially in this JSR the spirit and constructive contribution by community members already showed how it could work even more smoothly in some Open Source ecosystem for Java Enterprise...

Best Regards,
Werner


Re: Final Approval Ballot passes! :)

Rudy De Busscher
 

It was a unique experience to be involved in an EG and I learned a lot.

And Thanks to Arjan for the huge amount of work he has put into the spec. Without his work, there would be no vote at all if you ask me :)

I hope we can soon start with the security.NEXT version so that we can define all the initial ideas to make Java EE Security complete.

Best regards
Rudy


On 22 August 2017 at 14:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi all,

Today we passed our Final Approval Ballot:

https://jcp.org/en/jsr/results?id=6044

The result is an unanimous yes, with only Intel not having voted.

Thanks to everybody involved :) Without all of your help this would not have been possible!

As mentioned before, the JSR is *much* smaller than what we initially set out for, but it's an enormous step in the right direction as far as I'm concerned. Being so small may have its advantages even, as instead of getting an enormous framework dropped into their laps, users can now more gradually discover Java EE security.

The spec document can be found here, extra thanks to Will for taking care of that part so much:

http://download.oracle.com/otndocs/jcp/java_ee_security-1_0-pfd-spec/index.html

For now there's a few tiny bugs left in the implementation (Soteria), but nothing preventing a 1.0 release. Of course, as happens for each and every RI out there, incremental updates (Soteria 1.0.1, 1.1 etc) should be released with some frequency to address whatever is going to be found and raised by the community.

Kind regards,
Arjan Tijms



Re: Final Approval Ballot passes! :)

Guillermo González de Agüero
 

Hi all,

Thanks everyone involved in this important work.

Arjan, you're a true example of commitment and we all know we wouldn't be here without all the work you've put into this from way before the JSR was even initiated. Your deep compromise with the Java EE world and specially your kind interest in helping and explaining concepts to everyone were some of the forces that motivated me to collaborate on this and be more engaged on Java EE in general.

Will, you were assigned the difficult mission of finishing an extremely important and nearly-done JSR within a short amount of time. As Arjan says the spec has finally seen its scope drastically reduced but I personally think the spec and API are now a much more solid foundation than it was when you started. I really appreciate the many hours you've put into this and I'm sure the community as a whole will enjoy the results very soon with Java EE 8.

I've really enjoyed this journey and I'm grateful for what we have obtained. Even being smaller that originally expected, an historical gap in Java EE has been closed.

Congratulations and thanks again to everybody. I hope to see you all again on Security.NEXT


Regards,

Guillermo González de Agüero

El mar., 22 de agosto de 2017 14:38, Arjan Tijms <arjan.tijms@...> escribió:
Hi all,

Today we passed our Final Approval Ballot:

https://jcp.org/en/jsr/results?id=6044

The result is an unanimous yes, with only Intel not having voted.

Thanks to everybody involved :) Without all of your help this would not have been possible!

As mentioned before, the JSR is *much* smaller than what we initially set out for, but it's an enormous step in the right direction as far as I'm concerned. Being so small may have its advantages even, as instead of getting an enormous framework dropped into their laps, users can now more gradually discover Java EE security.

The spec document can be found here, extra thanks to Will for taking care of that part so much:

http://download.oracle.com/otndocs/jcp/java_ee_security-1_0-pfd-spec/index.html

For now there's a few tiny bugs left in the implementation (Soteria), but nothing preventing a 1.0 release. Of course, as happens for each and every RI out there, incremental updates (Soteria 1.0.1, 1.1 etc) should be released with some frequency to address whatever is going to be found and raised by the community.

Kind regards,
Arjan Tijms


Final Approval Ballot passes! :)

Arjan Tijms
 

Hi all,

Today we passed our Final Approval Ballot:

https://jcp.org/en/jsr/results?id=6044

The result is an unanimous yes, with only Intel not having voted.

Thanks to everybody involved :) Without all of your help this would not have been possible!

As mentioned before, the JSR is *much* smaller than what we initially set out for, but it's an enormous step in the right direction as far as I'm concerned. Being so small may have its advantages even, as instead of getting an enormous framework dropped into their laps, users can now more gradually discover Java EE security.

The spec document can be found here, extra thanks to Will for taking care of that part so much:

http://download.oracle.com/otndocs/jcp/java_ee_security-1_0-pfd-spec/index.html

For now there's a few tiny bugs left in the implementation (Soteria), but nothing preventing a 1.0 release. Of course, as happens for each and every RI out there, incremental updates (Soteria 1.0.1, 1.1 etc) should be released with some frequency to address whatever is going to be found and raised by the community.

Kind regards,
Arjan Tijms


Re: Need comment on Issue #174 ASAP

Will Hopkins
 

Thanks, Arjan.

FYI, PR #177 adds the call to proceed(), if you want to have a look. The SecurityManager aspect is puzzling, but I suspect it's actually unrelated, or is related only because an access control problem of some kind masked or unmasked the underlying problem.

Will

On 08/17/2017 10:36 AM, Arjan Tijms wrote:
Hi,

Just saw this coming in so sorry for the somewhat late reply.

I'm indeed pretty sure it needs to call `invocationContext.proceed()` like you mention. The moment it calls this probably doesn't even matter that much. It can either do it before it cleans up its own cookie or afterwards.

I do wonder about the SecurityManager involvement in the failure here, but it's hard to comment on that since I don't know the "cleanSubject" test exactly does or doesn't.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Need comment on Issue #174 ASAP

Arjan Tijms
 

Hi,

Just saw this coming in so sorry for the somewhat late reply.

I'm indeed pretty sure it needs to call `invocationContext.proceed()` like you mention. The moment it calls this probably doesn't even matter that much. It can either do it before it cleans up its own cookie or afterwards.

I do wonder about the SecurityManager involvement in the failure here, but it's hard to comment on that since I don't know the "cleanSubject" test exactly does or doesn't.

Kind regards,
Arjan Tijms


Re: Need comment on Issue #174 ASAP

Will Hopkins
 

Comments from other EG members/Contributors also welcome ... ;)

On 08/17/2017 08:14 AM, Will Hopkins wrote:
Arjan,

Can you have a look at #174, and let me know what you think ASAP?

To summarize, I think the RememberMeInterceptor must call invocationContext.proceed(), to delegate to the other interceptors/underlying HAM, when intercepting cleanSubject().

The spec says only that it must call rememberMeIdentityStore.removeLoginToken(), which is indeed necessary, but not sufficient -- the Subject is never cleaned.

I'm preparing a commit to implement this in Soteria, but would appreciate your review, as this is a significant behavior change in an area the spec is silent on.

Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Need comment on Issue #174 ASAP

Will Hopkins
 

Arjan,

Can you have a look at #174, and let me know what you think ASAP?

To summarize, I think the RememberMeInterceptor must call invocationContext.proceed(), to delegate to the other interceptors/underlying HAM, when intercepting cleanSubject().

The spec says only that it must call rememberMeIdentityStore.removeLoginToken(), which is indeed necessary, but not sufficient -- the Subject is never cleaned.

I'm preparing a commit to implement this in Soteria, but would appreciate your review, as this is a significant behavior change in an area the spec is silent on.

Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Branches to prune in JSR-375 repos

Will Hopkins
 

That was used to collect changes between the PFD draft and the draft that was submitted for FAB.

On 08/15/2017 02:10 PM, Werner Keil wrote:
  • pfd2, what was the purpose of that?

I guess with release tags for all major milestones like PFD or FAB, this branch does not need to be preserved either.

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Branches to prune in JSR-375 repos

Werner Keil
 

  • pfd2, what was the purpose of that?

I guess with release tags for all major milestones like PFD or FAB, this branch does not need to be preserved either.

Werner


Branches to prune in JSR-375 repos

Will Hopkins
 

All,

It looks to me as if the following branches can be pruned from the JSR-375 repos. Any objections? I won't do this soon, but please let me know asap if any of them need to be preserved.

github.com/javaee/security-spec:
  • arjantijms-AutoApplySession
  • arjantijms-LoginToContinue
  • build-in-mechanisms
  • pfd2
github.com/javaee/security-api:
  • ggam-patch-1
  • hashalgorithm
github.com/javaee/security-soteria:
  • bundle
  • hashalgorithm
  • multistores
Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Move security-examples repo to Java EE org at GitHub?

Will Hopkins
 

OK, I'll do that then.

To summarize:
  • I'll move the security-examples repo to the Java EE org, probably within the next several days.
  • At some point soon, I'll preserve the "authorization" proposals from security-proposals, as a security-spec issue, with the code content either attached to the issue or preserved in gh-pages there.
  • I will then delete the remaining, unneeded repos at github.com/javaee-security-spec (i.e., security-spec, which has been cloned to github.com/javaee, and security-proposals, which will no longer have any content that we need to preserve), and the github.com/javaee-security-spec organization itself.
I'm in no hurry to do anything except move the security-examples repo, but will proceed with the rest at some point over the next several weeks if I don't hear any objections.

Regards,

Will

On 08/15/2017 01:29 PM, Guillermo González de Agüero wrote:


El mar., 15 de agosto de 2017 18:11, Will Hopkins <will.hopkins@...> escribió:
Werner, I'm not sure what this is in reference to. Is it the security-proposals repo?

If so, I think the question is about the nature and value of the content, and whether, therefore, it should be preserved.

I just took a look at what's there, and I think we actually implemented almost all of it -- everything except the "authorization" module -- so maybe the thing to do is to zip up the authorization module, and attach it to a security-spec issue for a future 1.1 or MR release. That way it will be available as a starting point for any future work we undertake. (If we can't attach files, perhaps we can check it into gh-pages and link to it from the issue.)
I was about to propose that. Moving it to the gh-pages branch (or another "proposals" branch, linked from the website) would be enough for me. That, in addition to the old java.net documents would constitute a solid historic reference.


Does that seem reasonable?


On 08/15/2017 12:02 PM, Werner Keil wrote:
Adam had this "Java EE Best Practices" repo once, but it may have died with kenai.com.

Java EE Examples would sound more like the examples, but in theory https://github.com/javaee-samples could host the proposals, because it has a lot of fancy stuff like Docker or JBoss Forge samples.

Arjan, do you have admin rights there? Or somebody else?
Otherwise I could only think of a personal repo by someone.

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Move security-examples repo to Java EE org at GitHub?

Werner Keil
 

It could be in the issue tracker, a Wiki (if the project uses that) or just parts of the project site, as long as the ideas are there to discuss and maybe act further.
A lot of the code was merely like a "Gist" so not as valuable as the "User Stories" behind it.

Werner


Re: Move security-examples repo to Java EE org at GitHub?

Guillermo González de Agüero
 



El mar., 15 de agosto de 2017 18:11, Will Hopkins <will.hopkins@...> escribió:
Werner, I'm not sure what this is in reference to. Is it the security-proposals repo?

If so, I think the question is about the nature and value of the content, and whether, therefore, it should be preserved.

I just took a look at what's there, and I think we actually implemented almost all of it -- everything except the "authorization" module -- so maybe the thing to do is to zip up the authorization module, and attach it to a security-spec issue for a future 1.1 or MR release. That way it will be available as a starting point for any future work we undertake. (If we can't attach files, perhaps we can check it into gh-pages and link to it from the issue.)
I was about to propose that. Moving it to the gh-pages branch (or another "proposals" branch, linked from the website) would be enough for me. That, in addition to the old java.net documents would constitute a solid historic reference.


Does that seem reasonable?


On 08/15/2017 12:02 PM, Werner Keil wrote:
Adam had this "Java EE Best Practices" repo once, but it may have died with kenai.com.

Java EE Examples would sound more like the examples, but in theory https://github.com/javaee-samples could host the proposals, because it has a lot of fancy stuff like Docker or JBoss Forge samples.

Arjan, do you have admin rights there? Or somebody else?
Otherwise I could only think of a personal repo by someone.

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Move security-examples repo to Java EE org at GitHub?

Werner Keil
 

I'd say take a look at everything that may not be done yet, and probably create a "candidate" GitHub ticket either in the Spec or API project?;-)


Re: Move security-examples repo to Java EE org at GitHub?

Will Hopkins
 

Werner, I'm not sure what this is in reference to. Is it the security-proposals repo?

If so, I think the question is about the nature and value of the content, and whether, therefore, it should be preserved.

I just took a look at what's there, and I think we actually implemented almost all of it -- everything except the "authorization" module -- so maybe the thing to do is to zip up the authorization module, and attach it to a security-spec issue for a future 1.1 or MR release. That way it will be available as a starting point for any future work we undertake. (If we can't attach files, perhaps we can check it into gh-pages and link to it from the issue.)

Does that seem reasonable?

On 08/15/2017 12:02 PM, Werner Keil wrote:
Adam had this "Java EE Best Practices" repo once, but it may have died with kenai.com.

Java EE Examples would sound more like the examples, but in theory https://github.com/javaee-samples could host the proposals, because it has a lot of fancy stuff like Docker or JBoss Forge samples.

Arjan, do you have admin rights there? Or somebody else?
Otherwise I could only think of a personal repo by someone.

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Move security-examples repo to Java EE org at GitHub?

Werner Keil
 

Adam had this "Java EE Best Practices" repo once, but it may have died with kenai.com.

Java EE Examples would sound more like the examples, but in theory https://github.com/javaee-samples could host the proposals, because it has a lot of fancy stuff like Docker or JBoss Forge samples.

Arjan, do you have admin rights there? Or somebody else?
Otherwise I could only think of a personal repo by someone.

Werner


Move security-examples repo to Java EE org at GitHub?

Will Hopkins
 

All:

I'd like to make the security-examples repo an "official" repo for the JSR, and move it into the Java EE org. The GF doc/samples team is looking for JSR-375 samples, and it makes sense to me to keep this repo as the home for JSR-375 samples. Does that work for everyone?

Also, we'll eventually need to clean up/delete the javaee-security-spec org since the JSR's official home is now the Java EE org. There is a stale copy of the security-spec repo that can be deleted; other than that, and assuming security-examples is moved, the only remaining repo is the security-proposals where, if I understand the history, some of the initial proposals/POCs were kept.

Do we need the security-proposals repo? If so, which content specifically? Could it be kept somewhere else?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: ACTION REQUIRED: JSR-375 Expert Group

Bill Shannon
 

Will Hopkins wrote on 08/10/17 06:17 PM:
Bill,

So the category of "trivial" changes you describe corresponds to the description of errata in your JCP Processes writeup?
No, the kinds of trivial changes that might be make between FAB and Final Release are a small subset of errata.

That being the case, what JCP process applies to errata? I didn't see a reference to it on the process or spec lead pages (though I didn't do a deep dive). Is errata something I can just do? Does it get vetted or approved somehow? How do I document it (i.e., with a change list or something)?
As the page says:

Which process do I use for which change?

We always use the Maintenance Release process for spec errata.



Lastly, would acknowledgements fall into the category of errata? I'd like to acknowledge Alex Kosowski's role as spec lead getting the JSR off the ground.
I would consider that a trivial change.


Re: JSR-375 Session at JavaOne

Werner Keil
 

Guess I'm good with fewer JavaOne talks now anyway, because M2M Summit approved my talk right after JavaOne in Germany. 
And after it was at Messe Düsseldorf a few years, this time it gets co-located with StartupCon in LANXSS Arena Cologne: http://www.lanxess-arena.de/events/eventkalender.html
After Metallica gave 2 concerts there and Helene Fischer 6 right before M2M Summit.
So a real Rock Star venue, the kind of place Adam might usually talk at ;-)

I did sessions on this topic (Quantified Social) from Social Media Weeks (also big events with Thousands of attendees total) to JavaLand, but I guess I'll try to brush it up a bit.
And hopefully I could use Agorava 1.0 underneath the hood of Quantifier, then the audience should also see a bit of JSR 375 in action (Agorava 1.0 is meant to use Java EE 8 and Soteria)

Could be a nice opportunity to make Dozens or even Hundreds of aspiring Startup founders aware of Java Security and EE 8...

Werner

81 - 100 of 736