Date   

Re: What's our Acronym?

reza_rahman <reza_rahman@...>
 

Sounds good to me.

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 8/3/17 9:45 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] What's our Acronym?

How about simply "JSA"?

Java EE
Security
API


-David


On Thu, Aug 3, 2017 at 5:16 PM, Will Hopkins <will.hopkins@...> wrote:
JSR-375 needs an acronym -- there are times when neither JSR-375 nor "Java EE Security API" are appropriate in context -- block diagrams showing all the Java EE technologies, for example.

I seem to recall people weren't very enthusiastic about JESAPI or JSAPI -- how about SECAPI? Any other ideas?

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



Re: What's our Acronym?

David Blevins
 

How about simply "JSA"?

Java EE
Security
API


-David


On Thu, Aug 3, 2017 at 5:16 PM, Will Hopkins <will.hopkins@...> wrote:
JSR-375 needs an acronym -- there are times when neither JSR-375 nor "Java EE Security API" are appropriate in context -- block diagrams showing all the Java EE technologies, for example.

I seem to recall people weren't very enthusiastic about JESAPI or JSAPI -- how about SECAPI? Any other ideas?

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



What's our Acronym?

Will Hopkins
 

JSR-375 needs an acronym -- there are times when neither JSR-375 nor "Java EE Security API" are appropriate in context -- block diagrams showing all the Java EE technologies, for example.

I seem to recall people weren't very enthusiastic about JESAPI or JSAPI -- how about SECAPI? Any other ideas?

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


Re: ACTION REQUIRED: JSR-375 Expert Group

Arjan Tijms
 


On Thu, Aug 3, 2017 at 12:14 PM, Werner Keil <werner.keil@...> wrote:
In 2.5 of the Spec, was referring to CDI 1.2, not 2.0 (which is included in Java EE 8 and Final by now) on page 22 deliberate?

The dependencies are also Java EE 7, so as the minimum version for CDI it sounds OK.

Indeed. I think this came up during one of the calls or perhaps on the list (can't quite remember) as well. We would have loved to take advantage of some of the CDI 2.0 features, but in the end it didn't happen. So everything is exclusively based on Java EE 7 APIs, perhaps unfortunately, but the upside is that the RI can be used on existing EE 7 servers as well.

Kind regards,
Arjan


 



Re: ACTION REQUIRED: JSR-375 Expert Group

Werner Keil
 

I saw, these exist in multiple places, so Servlet and EJB are mentioned in different chapters like 4.5

Nevertheless, I believe JDBC 4 should be mentioned and a reference added in 3.5 as the  @DatabaseIdentityStoreDefinition.
is part of chapter 3.


Re: ACTION REQUIRED: JSR-375 Expert Group

Werner Keil
 

Chapter 3.5 of the spec IMO is missing references to Servlet (it already exists and linked in the text as  [SERVLET31]), EJB (same for [EJB32]) and possibly JDBC 4 (JSR 221) as a default data source is used in @DatabaseIdentityStoreDefinition.

None are significant show-stoppers, but would be nice to have them in a final 1.0 version of the spec.

I should be able to fill out my OCA, but if others could factor that into the spec faster, please do.

Werner


Re: ACTION REQUIRED: JSR-375 Expert Group

Werner Keil
 

In 2.5 of the Spec, was referring to CDI 1.2, not 2.0 (which is included in Java EE 8 and Final by now) on page 22 deliberate?

The dependencies are also Java EE 7, so as the minimum version for CDI it sounds OK.


Re: ACTION REQUIRED: JSR-375 Expert Group

Werner Keil
 

It could be done via a MR, but especially in Java EE those things always take a bit before they get into updates of the umbrella standard or new products.


Re: ACTION REQUIRED: JSR-375 Expert Group

David Blevins
 

Hi Will,

I think the JSR is overall a step forward and I support it.

Like Arjan I also have a “too bad this missed the boat” list item.  When the spec launched in 2015, the need for JWTs were a bit fuzzy.  At some point between then and now their need became crystal clear.  I kick myself in the butt for not coming back and pushing for them sooner while there was still time :)

We will live to fight another day, what we have is a solid foundation, you’ve been an great lead and I really look forward to the next round!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Aug 1, 2017, at 4:29 PM, Will Hopkins <will.hopkins@...> wrote:

FYI, this message was also sent directly to EG members.


-------- Forwarded Message --------
Subject: ACTION REQUIRED: JSR-375 Expert Group
Date: Tue, 1 Aug 2017 19:26:38 -0400
From: Will Hopkins <will.hopkins@...>
To:


Expert Group:

I am preparing to submit the attached draft of the JSR-375 spec for a Final Approval Ballot. As part of the process, I need to confirm that the Expert Group agrees the JSR is ready to go to Final Release.

Members of the Expert Group, please reply to this mail to confirm that you agree the JSR is ready. Agreement will be assumed for Expert Group members who do not respond within 24 hours.

Thanks,

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

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
<jsr375-spec-1.0-fab.pdf>


FYI, Submitted FAB Materials to the JCP

Will Hopkins
 

The ballot is scheduled to start next Tuesday, August 8th.
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: ACTION REQUIRED: JSR-375 Expert Group

Will Hopkins
 

Thanks, Arjan.

I'll add these mistakes to an issue I created to today to track a couple other typos.

My understanding is we may have an opportunity to correct that sort of mistake during/after the final ballot process. We can't change the substance of the document, but, at a minimum, the license text needs to be updated, and I've been given the impression it would be permissible to fix typos, etc. It's also possible that objections will be raised during the ballot that would need to be addressed.

Will

On 08/02/2017 06:40 PM, Arjan Tijms wrote:
Hi,

The JSR is ready in my opinion.

We have largely achieved what we wanted to achieve, and the things that were not done are such that they can be done in a next release. It's somewhat of a personal regret of me that we didn't get to specify the additional planned methods for the SecurityContext (specifically the login() method), and that the CDI/JSR375 version of @RolesAllowed was not incorporated.

Nevertheless, these omissions in no way take away from the core value of the current work or influence its readiness for the JSR to be released.

A few small things here and there in the JSR would not have been my first choice, but as the JCP is of course about consensus and compromises, I can absolutely live with the versions of those things about which we reached consensus.

So overall I'm really happy with the result :)

As for the spec document, there's a few small additional things I noticed, but nothing major:

>This chapter overview information and terminology related to this specification, and also includes a general requirements not specified elsewhere in this document. 

This sentence doesn't read so well.

I guess it should be something like: "This chapter contains an overview of information ..."  and "includes general requirements ..."


>
 validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests to constrained as well as to unconstrained resources, and, in addition, in response to application code calling the authenticate() method on the HttpServletRequest

For completeness this should maybe include SecurityContext as well.

On page 21

>
 if (status.equals(IN_PROGRESS)) {
              facesContext.responseComplete();
          }
I just noticed this, but we forgot to update this status to the renamed version; "SEND_CONTINUE". As it's only an example it's not critical, but still...

Kind regards,
Arjan Tijms



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


Re: ACTION REQUIRED: JSR-375 Expert Group

Arjan Tijms
 

Hi,

The JSR is ready in my opinion.

We have largely achieved what we wanted to achieve, and the things that were not done are such that they can be done in a next release. It's somewhat of a personal regret of me that we didn't get to specify the additional planned methods for the SecurityContext (specifically the login() method), and that the CDI/JSR375 version of @RolesAllowed was not incorporated.

Nevertheless, these omissions in no way take away from the core value of the current work or influence its readiness for the JSR to be released.

A few small things here and there in the JSR would not have been my first choice, but as the JCP is of course about consensus and compromises, I can absolutely live with the versions of those things about which we reached consensus.

So overall I'm really happy with the result :)

As for the spec document, there's a few small additional things I noticed, but nothing major:

>This chapter overview information and terminology related to this specification, and also includes a general requirements not specified elsewhere in this document. 

This sentence doesn't read so well.

I guess it should be something like: "This chapter contains an overview of information ..."  and "includes general requirements ..."


>
 validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests to constrained as well as to unconstrained resources, and, in addition, in response to application code calling the authenticate() method on the HttpServletRequest

For completeness this should maybe include SecurityContext as well.

On page 21

>
 if (status.equals(IN_PROGRESS)) {
              facesContext.responseComplete();
          }
I just noticed this, but we forgot to update this status to the renamed version; "SEND_CONTINUE". As it's only an example it's not critical, but still...

Kind regards,
Arjan Tijms



Re: ACTION REQUIRED: JSR-375 Expert Group

Arjan Tijms
 

As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.


ACTION REQUIRED: JSR-375 Expert Group

Will Hopkins
 

FYI, this message was also sent directly to EG members.


-------- Forwarded Message --------
Subject: ACTION REQUIRED: JSR-375 Expert Group
Date: Tue, 1 Aug 2017 19:26:38 -0400
From: Will Hopkins <will.hopkins@...>
To:


Expert Group:

I am preparing to submit the attached draft of the JSR-375 spec for a Final Approval Ballot. As part of the process, I need to confirm that the Expert Group agrees the JSR is ready to go to Final Release.

Members of the Expert Group, please reply to this mail to confirm that you agree the JSR is ready. Agreement will be assumed for Expert Group members who do not respond within 24 hours.

Thanks,

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

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


Re: A couple of last-minute technical issues

Arjan Tijms
 

Hi,

Indeed, a did an initial pass through them recently, great if Will can do another pass.

For issues that still 100% apply, an alternative could be to give them a "SecurityAPI.Next" label or something like that, so that they clearly stand out. Otherwise closing would be okay, since a lot of them may apply in spirit but the wording or context is slightly outdated.

Kind regards,
Arjan


Re: A couple of last-minute technical issues

Will Hopkins
 

Yes, that carried over from java.net. Arjan has looked at a lot of these and closed them as implemented or will not do. I need to take another pass through as well, but mostly these are all things that we have decided to defer and I think need to be closed on that basis, with a label that allows them to be easily found for use by a follow-on JSR.

Will

On 07/31/2017 12:14 PM, Werner Keil wrote:
What about the "high priority" label btw, guess that was from JIRA and does not apply to 1.0 any more?
(otherwise a lot of high prio tickets would still be left;-O)

Regards,
Werner

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


Re: A couple of last-minute technical issues

Werner Keil
 

What about the "high priority" label btw, guess that was from JIRA and does not apply to 1.0 any more?
(otherwise a lot of high prio tickets would still be left;-O)

Regards,
Werner


A couple of last-minute technical issues

Will Hopkins
 

EG:

I've got a couple of last minute questions/concerns about the spec, which I've written up as issues:
Please have a look and comment.

Thanks,

Will


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


Re: IdentityStore/AuthenticationMechanism properties validation

Guillermo González de Agüero
 

No problem, let's postpone this and review again after the spec is released.

On Mon, Jul 31, 2017 at 8:34 AM, Will Hopkins <will.hopkins@...> wrote:
I'll defer to Arjan as to the wisdom of this, but it's almost certainly to late to implement this.

We're scheduled to deliver FAB materials to the JCP 7/31 (i.e., today), although I don't think we'll do so until Tuesday (8/1). We'll miss slip our FAB date a week if we don't deliver the materials by 8/2.

In order to deliver FAB materials we need the TCK to be done, and a clean run of tests against the RI.


On 07/28/2017 01:12 PM, Guillermo González de Agüero wrote:
Just a ping here as the FAB is scheduled for this Sunday. Does anyone have an opinion here?

Both implementation and spec changes should be minimal and I could work on them myself if you agree on this.


Regards,

Guillermo González de Agüero

El mié., 26 jul. 2017 a las 7:56, Guillermo González de Agüero (<z06.guillermo@...>) escribió:
Hi,

We already talked about validation of attributes ([1] and [2]) and canceling deployment in case of invalid ones. At that time we came to the conclusion that it was too difficult to do and that it was better not to standarize that behavior at this time.

But then with [3] I had another idea I'd like to propose to the EG. The other time we talked about the runtime validating properties for the stores. What I propose now is that identity stores themselves validate their parameters. I've thought of two posible ways:
- Add a "init() throws Exception" method to IdentityStore/HttpAuthenticationMechanism.
- Specify that an exception thrown from a @PostConstruct annotated method on an IdentityStore or HttpAuthenticationMechanism makes deployment fail. Only unchecked exceptions can be thrown on @PostConstruct methods.

This behavior is aligned with what Servlets/Singleton EJBs/eager ApplicationScoped CDI beans do. The only required change is that identity stores and authentication mechanism would need to be created at deployment time, to be able to cancel deployment if needed.

I'd go for the @PostConstruct alternative as it's the less intrusive and more "CDIish" way to do it. Changes to the spec and implementation are minimal, while providing users the ability to validate their own artifacts. This would also help [3] case reducing runtime exceptions to just unexpected ones.

What do you think?


Regards,

Guillermo González de Agüero:

[1] https://javaee.groups.io/g/javaee-security-spec/message/324
[2] https://github.com/javaee/security-soteria/issues/104
[3] https://github.com/javaee/security-soteria/pull/124

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



Re: IdentityStore/AuthenticationMechanism properties validation

Will Hopkins
 

I'll defer to Arjan as to the wisdom of this, but it's almost certainly to late to implement this.

We're scheduled to deliver FAB materials to the JCP 7/31 (i.e., today), although I don't think we'll do so until Tuesday (8/1). We'll miss slip our FAB date a week if we don't deliver the materials by 8/2.

In order to deliver FAB materials we need the TCK to be done, and a clean run of tests against the RI.

On 07/28/2017 01:12 PM, Guillermo González de Agüero wrote:
Just a ping here as the FAB is scheduled for this Sunday. Does anyone have an opinion here?

Both implementation and spec changes should be minimal and I could work on them myself if you agree on this.


Regards,

Guillermo González de Agüero

El mié., 26 jul. 2017 a las 7:56, Guillermo González de Agüero (<z06.guillermo@...>) escribió:
Hi,

We already talked about validation of attributes ([1] and [2]) and canceling deployment in case of invalid ones. At that time we came to the conclusion that it was too difficult to do and that it was better not to standarize that behavior at this time.

But then with [3] I had another idea I'd like to propose to the EG. The other time we talked about the runtime validating properties for the stores. What I propose now is that identity stores themselves validate their parameters. I've thought of two posible ways:
- Add a "init() throws Exception" method to IdentityStore/HttpAuthenticationMechanism.
- Specify that an exception thrown from a @PostConstruct annotated method on an IdentityStore or HttpAuthenticationMechanism makes deployment fail. Only unchecked exceptions can be thrown on @PostConstruct methods.

This behavior is aligned with what Servlets/Singleton EJBs/eager ApplicationScoped CDI beans do. The only required change is that identity stores and authentication mechanism would need to be created at deployment time, to be able to cancel deployment if needed.

I'd go for the @PostConstruct alternative as it's the less intrusive and more "CDIish" way to do it. Changes to the spec and implementation are minimal, while providing users the ability to validate their own artifacts. This would also help [3] case reducing runtime exceptions to just unexpected ones.

What do you think?


Regards,

Guillermo González de Agüero:

[1] https://javaee.groups.io/g/javaee-security-spec/message/324
[2] https://github.com/javaee/security-soteria/issues/104
[3] https://github.com/javaee/security-soteria/pull/124

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

161 - 180 of 736