Date   

Re: Restore write access for all EG members?

Arjan Tijms
 

Hi,

On Thu, Jun 1, 2017 at 6:46 PM, Will Hopkins <will.hopkins@...> wrote:
I think this is getting blown out of proportion. With the exception of a small change to who can approve a PR, nothing has changed.

I personally think this is fundamental though for the perception of the JSR.

Java EE JSRs have been opening up more over time and as a result became more successful. This cycle, JSF and Java EE Security have been particularly open and have been a great success.

It's not in either my or the other experienced EG members best interest either to make unwarranted and undiscussed changes. Trust and community engagement are important things and I feel that's currently not optimal this way. I'm absolutely sure that people like Werner, Ivar, Rudy and myself are just as careful as you would be.

You also mentioned wanting to close the Soteria RI, but that's IMHO certainly not needed. To the best of my knowledge, even the more conservative specs have not closed the implementation project for their regular committers. The Mojarra project, where I'm a committer as well, certainly did not do this.

 
Also, as others have noted, the soteria repo is still open to all, precisely because there is more work going on there, and because the RI is not as "public" as the API -- it's not documented as part of the spec -- and therefore has more capacity to absorb changes at this point in the process.

Indeed, it's still open, and really should stay open. There are lots of things that need to be done still that have no effect on the spec proper, not in the least expanding the test suite.

 

I did not expect this to be such a controversial change -- in my experience, it's a pretty typical practice used to keep code stable as a release approaches, and I did say, when I announced I was locking the repos, that I intended to keep the access limited after the PRD was published (although, in hindsight, I probably did not state it as clearly as I should have).

I'll give some thought to opening this back up, but I want to re-iterate the basic concerns here:
  • The spec and the API need stability going forward. That doesn't mean they can't change, but changes need to be well-considered and discussed with the EG before going in.
Absolutely, and that is I think the understanding of everyone. We're all experienced and dedicated people here, so taking myself as example, there really should be no need to assume I would suddenly do a large undiscussed commit.

 
  • Along the same lines, I need to be OK with the changes that are going in. This may feel unfair to some -- I'm the new guy, and wasn't around while most of the original work was going on. Many of you have greater expertise in particular areas of EE than I do. But that is the spec lead's job, and I think the perspective I bring from an app server vendor POV is important if JSR-375 is to be successful.

I think nobody is saying that the app server vendor POV is not important, of course it is. But don't forget that I work for an app server vendor as well, so your concern is the same as my concern ;)

Ideally, in my vision of the JCP process, there should be representatives from every POV in the EG. The library vendor, the app server vendor, the consultant, the "regular" application developer, the big enterprise, the smaller company and what have you. But the spec lead should not directly be representing any of these POVs, but ideally, in my opinion, should be balancing the concerns of all of those.


  • As well, there is a "tail" of work for the Oracle GlassFish and TCK teams that emanates from changes to the spec and the API (and, for that matter, from the RI). That tail is invisible to the EG, but it impacts our ability to deliver the JSR on time. It's something that, as spec lead, I need to be mindful of.
I know this all too well indeed, as we've recently finished the JSF spec in which I had a major role.

As far as the TCK is concerned, I'd really like to contribute to that as well in whatever shape or form (I'll start a separate thread for this).

 
  • I disagree with the idea that it's just as easy to roll back a commit as it is to institute change control on incoming PRs. The technical effort may be similar to merging a new change (for both simple and complex cases), but in my view there's a higher bar when arguing to roll back a change than there is when arguing that a change shouldn't go in. It also creates more code churn to commit, then roll back, changes that shouldn't go in.

The crux of the problem here as I see it, is that the assumption is then that there are going to be many such reverts.

My assumption is that there won't be much if any such revert needed, as we're all experienced and responsible people here. If a revert would ever be needed since it broke something, then I'm sure such a revert might just as well have been needed if it happened via an approved PR.

We didn't do any rash commits when the spec lead was no where near in sight and we still had all the time in the world. For example, I did *a lot* of work for the authorization rules story last July and August, but I didn't put that in the spec since I felt not enough EG feedback had been given after I presented it.

 
  • Thanks for your patience. I'm going to give this some thought, and talk to a few people privately, and I may open things back up, at least to some degree.

Okay, thanks in advance for that :)

 
P.S. Regarding the naming scheme for our repos under the javaee org, they will all be prefixed by "security-", so that they are easy to find. Two of the repos already have the "security-" prefix. The soteria repo will be renamed to "security-soteria".

Sounds good!

Kind regards,
Arjan Tijms

 



On 06/01/2017 03:36 AM, Rudy De Busscher wrote:
Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




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



Re: Restore write access for all EG members?

Will Hopkins
 

The names of the JSR-375 repos under the javaee organization will be:

github.com/javaee/security-api
github.com/javaee/security-soteria
github.com/javaee/security-spec

Will

On 06/01/2017 01:56 AM, Arjan Tijms wrote:
On Thu, Jun 1, 2017 at 7:47 AM, Ivar Grimstad <ivar.grimstad@...> wrote:
One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

That's unfortunate indeed. A very good hyphen naming scheme could somewhat alleviate that, but it's still not as nice as a real sub-org. E.g.


(api-api looks a bit weird here)

 
For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Something to think about for sure.

Thanks!

Kind regards,
Arjan Tijms

 

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner

--

Java Champion, JCP EC/EG Member, JUG Leader



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


Re: Restore write access for all EG members?

Will Hopkins
 

I think this is getting blown out of proportion. With the exception of a small change to who can approve a PR, nothing has changed.

Anybody who wants to submit a PR against security-spec or security-api can still do so. All PRs will be reviewed in a timely fashion, and potentially committed. This is not materially different from what the situation was two weeks ago, except that the list of approvers is shorter than it was. It is not the case that we are no longer accepting commits, and there is no need to create new repos to do work.

Also, as others have noted, the soteria repo is still open to all, precisely because there is more work going on there, and because the RI is not as "public" as the API -- it's not documented as part of the spec -- and therefore has more capacity to absorb changes at this point in the process.

I did not expect this to be such a controversial change -- in my experience, it's a pretty typical practice used to keep code stable as a release approaches, and I did say, when I announced I was locking the repos, that I intended to keep the access limited after the PRD was published (although, in hindsight, I probably did not state it as clearly as I should have).

I'll give some thought to opening this back up, but I want to re-iterate the basic concerns here:
  • The spec and the API need stability going forward. That doesn't mean they can't change, but changes need to be well-considered and discussed with the EG before going in. Our date to produce a final draft is less than one month away, given the lead time the JCP requires to publish.
  • Along the same lines, I need to be OK with the changes that are going in. This may feel unfair to some -- I'm the new guy, and wasn't around while most of the original work was going on. Many of you have greater expertise in particular areas of EE than I do. But that is the spec lead's job, and I think the perspective I bring from an app server vendor POV is important if JSR-375 is to be successful. As well, there is a "tail" of work for the Oracle GlassFish and TCK teams that emanates from changes to the spec and the API (and, for that matter, from the RI). That tail is invisible to the EG, but it impacts our ability to deliver the JSR on time. It's something that, as spec lead, I need to be mindful of.
  • I disagree with the idea that it's just as easy to roll back a commit as it is to institute change control on incoming PRs. The technical effort may be similar to merging a new change (for both simple and complex cases), but in my view there's a higher bar when arguing to roll back a change than there is when arguing that a change shouldn't go in. It also creates more code churn to commit, then roll back, changes that shouldn't go in.
Thanks for your patience. I'm going to give this some thought, and talk to a few people privately, and I may open things back up, at least to some degree.

Meanwhile, please feel free to submit PRs against any of the repos for changes you think are needed. The soteria repo is still wide open, and PRs for the spec and API repos will be reviewed promptly.

Thanks,

Will

P.S. Regarding the naming scheme for our repos under the javaee org, they will all be prefixed by "security-", so that they are easy to find. Two of the repos already have the "security-" prefix. The soteria repo will be renamed to "security-soteria".


On 06/01/2017 03:36 AM, Rudy De Busscher wrote:
Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




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


Re: Restore write access for all EG members?

Rudy De Busscher
 

Arjan,

Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api.
I had the impression from the communication by Will that Soteria (as it is the RI) was also locked.

Another clone will make this only more complicated, the original repositories need to be in maintained good shape.

Rudy


On 1 June 2017 at 07:45, Arjan Tijms <arjan.tijms@...> wrote:
For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms




Re: Restore write access for all EG members?

Arjan Tijms
 

On Thu, Jun 1, 2017 at 7:47 AM, Ivar Grimstad <ivar.grimstad@...> wrote:
One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

That's unfortunate indeed. A very good hyphen naming scheme could somewhat alleviate that, but it's still not as nice as a real sub-org. E.g.


(api-api looks a bit weird here)

 
For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Something to think about for sure.

Thanks!

Kind regards,
Arjan Tijms

 

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


--

Java Champion, JCP EC/EG Member, JUG Leader



Re: Restore write access for all EG members?

Ivar Grimstad
 

One comment regarding transfer of the repos to the JavaEE organization. Keep in mind that GitHub does not currently support sub-organizations, so all our repos will be spread out there.

For MVC we have chosen to only have the spec (doc+api) in the Java EE organization as a read-only mirror. All work is done in the mvc-spec GitHub organization where we have the spec, ri and tck as well as proposals and samples all gathered together.

Ivar

On Thu, Jun 1, 2017 at 7:13 AM Rudy De Busscher <rdebusscher@...> wrote:
Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


--

Java Champion, JCP EC/EG Member, JUG Leader


Re: Restore write access for all EG members?

Arjan Tijms
 

For the moment https://github.com/javaee-security-spec/soteria is still writable, so we can fix things there for now.

An alternative btw is to setup a new org for all EG members, say https://github.com/javaee-security-spec-eg and then clone security-api and soteria into that. Everyone can then do PRs against those cloned repos and EG members can accept them. From the cloned repos we can then do a PR again against the https://github.com/javaee-security-spec repos.

With that setup we always have an integrated experimental version of the Java EE Security API that can be shared and used for demos etc.

Thoughts?

Kind regards,
Arjan Tijms



Re: Restore write access for all EG members?

Rudy De Busscher
 

Does this mean we no longer can help by writing code?

At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I need to give at JDK.IO in about 2 weeks.

I started also to create issues for the bugs I have discovered, so at least there is a trace of the work which needs to be done before we can go final.

Rudy

On 31 May 2017 at 23:54, Werner Keil <werner.keil@...> wrote:
See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner



Re: Discussion: SecurityContext

Arjan Tijms
 

Hi,

The general use case for the method is letting the application find out whether a caller has access to certain resources and (mainly) adjusting rendering of links based on that.

A specific use case of this is dynamically rendering a menu with links to pages present in an application, based on what a user is allowed to access. Menu entries could be entirely omitted (so the user only sees entries to pages that are accessible, a common case), or could be rendered differently (say in red, or with a lock symbol next to it).

An extremely simplified example of this can be seen in a small demo app we did here: 


When menus are a little bit more sophisticated, there's often a need to know upfront about entire patterns of pages, for example when testing for /admin/* fails we can omit the entire admin sub header including introduction text. Otherwise we would need to see if the user has access to at least one page.

Roles can be used, and they are in practice, but that assumes the rendering code has knowledge of which role corresponds to which resource, something which doesn't allows remain stable and then necessitates updating code at multiple locations.

A use case where the EJB module could use knowledge about this is as mentioned when sending out emails, which is often done from business services. Another one woud be where an EJB module calls an internal (rest) service. I agree that the EJB module needing to know about the web permissions would be far less common, and would even be more practical with a method that, as Will suggested earlier, also took a Principal as input (things like email sending often happens in batches and asynchronously).

A hasAccessTo is an existing method that has been in use with various frameworks in different forms for some time. One of these is our own OmniFaces project, where we have implemented this here in a slightly different variant:


Hope this made it more clear.

Kind regards,
Arjan Tijms









On Thu, Jun 1, 2017 at 1:02 AM, Bill Shannon <bill.shannon@...> wrote:
Using JNDI-style names for resource names would be confusing.

What's the use case for this method in general, and for using this method with a resource that's in another module?

Arjan Tijms wrote on 05/31/17 03:51 PM:
Hi,

On Thu, Jun 1, 2017 at 12:28 AM, Bill Shannon <bill.shannon@...> wrote:
As I read the spec, the resource name is relative to the web module.  If you're not in a web container, what names can you use?  If your app has two war files, which web module is the name relative to?  Presumably the one you're running in, which means it's not useful if you're not running in a web container.  Well, unless the EJB module is exposing web services of some sort.

You're absolutely right, good catch!

Okay, I was wrong here then. When called from another container or "entry point" into the application (not sure what you would call inflow into a JCA connector exactly), you cannot just call that method.

For a next spec release I could imagine a JNDI like namespace prefix, with java:app/[module name] querying for a specific module in the application and java:module being the default for the current module (which would then throw an IllegalArgumentException if called from an EJB module).

E.g.

From an EJB:

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2

/admin
java:module/admin

Throws IllegalArgumentException 

----

From web module app1

/admin
java:module/admin

Queries for /admin for app1, where /admin must be treated equal to java:module/admin

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2, where java:app/app1/admin must be treated equal to java:module/admin

Thoughts?

Kind regards,
Arjan Tijms




 





Re: Discussion: SecurityContext

Bill Shannon
 

Using JNDI-style names for resource names would be confusing.

What's the use case for this method in general, and for using this method with a resource that's in another module?

Arjan Tijms wrote on 05/31/17 03:51 PM:

Hi,

On Thu, Jun 1, 2017 at 12:28 AM, Bill Shannon <bill.shannon@...> wrote:
As I read the spec, the resource name is relative to the web module.  If you're not in a web container, what names can you use?  If your app has two war files, which web module is the name relative to?  Presumably the one you're running in, which means it's not useful if you're not running in a web container.  Well, unless the EJB module is exposing web services of some sort.

You're absolutely right, good catch!

Okay, I was wrong here then. When called from another container or "entry point" into the application (not sure what you would call inflow into a JCA connector exactly), you cannot just call that method.

For a next spec release I could imagine a JNDI like namespace prefix, with java:app/[module name] querying for a specific module in the application and java:module being the default for the current module (which would then throw an IllegalArgumentException if called from an EJB module).

E.g.

From an EJB:

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2

/admin
java:module/admin

Throws IllegalArgumentException 

----

From web module app1

/admin
java:module/admin

Queries for /admin for app1, where /admin must be treated equal to java:module/admin

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2, where java:app/app1/admin must be treated equal to java:module/admin

Thoughts?

Kind regards,
Arjan Tijms




 




Re: Discussion: SecurityContext

Arjan Tijms
 

Hi,

On Thu, Jun 1, 2017 at 12:28 AM, Bill Shannon <bill.shannon@...> wrote:
As I read the spec, the resource name is relative to the web module.  If you're not in a web container, what names can you use?  If your app has two war files, which web module is the name relative to?  Presumably the one you're running in, which means it's not useful if you're not running in a web container.  Well, unless the EJB module is exposing web services of some sort.

You're absolutely right, good catch!

Okay, I was wrong here then. When called from another container or "entry point" into the application (not sure what you would call inflow into a JCA connector exactly), you cannot just call that method.

For a next spec release I could imagine a JNDI like namespace prefix, with java:app/[module name] querying for a specific module in the application and java:module being the default for the current module (which would then throw an IllegalArgumentException if called from an EJB module).

E.g.

From an EJB:

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2

/admin
java:module/admin

Throws IllegalArgumentException 

----

From web module app1

/admin
java:module/admin

Queries for /admin for app1, where /admin must be treated equal to java:module/admin

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2, where java:app/app1/admin must be treated equal to java:module/admin

Thoughts?

Kind regards,
Arjan Tijms




 



Re: Discussion: SecurityContext

Bill Shannon
 

Arjan Tijms wrote on 05/31/17 03:41 AM:
Hi,

On Wed, May 31, 2017 at 12:31 PM, Werner Keil <werner.keil@...> wrote:

If that's the case, this method should probably go into a Servlet specific interface or class. Otherwise please let's try to name and document it in a way that does not tie it to a single implementation or container.


Do note that while the method gives an outcome for a Servlet container resource, it should be perfectly valid to query it from any other containers.

E.g. an EJB bean composing an email message on behalf of a caller with an http link in that email.
I assume this is about hasAccessToWebResource...

As I read the spec, the resource name is relative to the web module.  If you're not in a web container, what names can you use?  If your app has two war files, which web module is the name relative to?  Presumably the one you're running in, which means it's not useful if you're not running in a web container.  Well, unless the EJB module is exposing web services of some sort.


Re: Restore write access for all EG members?

Werner Keil
 

See https://javaee.groups.io/g/jsonp-spec/topic/attention_to_experts/5073771?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5073771
Dmitry also described how EG members can join the organization and gain write access if they need to.
I did to help the transition of the project site to the new URL under gh-pages.

Werner


Re: Restore write access for all EG members?

Arjan Tijms
 

Hi,

What can I say? It would have been just as easy to announce to the group that the repo was effectively locked until further notice while preparing the PRD. You can additionally always take a note of the revision number to see what the exact version for the PRD is, or create a tag even.

That's exactly what Ed Burns and Manfred Riem did for JSF and everyone kept to that. Actually revoking the access, well intended or not, is IMHO not the right way to go forward with this.

It may be work to revert, but it's also work to let you be the bottleneck. As for the cost, it's generally known that an optimistic lock is cheaper than a pessimistic lock. Assuming that there's surely going to be reverting done is a pessimistic lock, and I'm sure you didn't intent it to be but almost by definition a pessimistic lock comes across as, well, pessimistic.

There's an amount of mundane work to be done, like moving things to the agreed javax.security.enterprise package. The PR for that can be immediately approved after quick review by basically any experienced EG member. This also makes it much easier to start the next PR right away and minimises the chances of merge conflicts.

The suite of tests is in the /test folder here https://github.com/javaee-security-spec/soteria/tree/master/test

I run them prior to every change and commit, and since I'm only human I could of course make a mistake and run them against the wrong version or something like that, so there's a CI job as well that also runs the entire test suite.

Kind regards,
Arjan Tijms




On Wed, May 31, 2017 at 10:54 PM, Will Hopkins <will.hopkins@...> wrote:
First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will



On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

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

--

Java Champion, JCP EC/EG Member, JUG Leader


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



Re: Restore write access for all EG members?

reza_rahman <reza_rahman@...>
 

I agree ultimately you should do what you are truly comfortable with as specification lead (within reason of course). If you had any general questions, Bill and Linda could provide guidance.

-------- Original message --------
From: Will Hopkins <will.hopkins@...>
Date: 5/31/17 4:54 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] Restore write access for all EG members?

First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will


On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

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

--

Java Champion, JCP EC/EG Member, JUG Leader


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


Re: Restore write access for all EG members?

Will Hopkins
 

First of all, I'd like to say that I understand and appreciate the tremendous contributions from the EG and all contributors. I especially appreciate Arjan's contributions -- my understanding is that he contributed most of the original code, and he's contributed a great deal to the spec itself.

I would also like to acknowledge that I am new to the business of being a spec lead, and that I am new to this JSR in particular, having become spec lead after much of the work to define the APIs and build the RI had already been done. So there may be aspects of the spec lead role that I'm misinterpreting, or don't fully appreciate, and there are definitely aspects of JSR-375 that I don't understand as well as most of you.

That said, it's my understanding that I am ultimately responsible for delivering the spec, the API, the RI, and the TCK. I'm responsible for meeting the schedule, and for the quality of the resulting deliverables. While I will always strive for consensus and agreement, it's also my understanding that I have both the responsibility, and the authority, to make the final decision on any question affecting the technical content of the JSR.

In my experience, it's necessary to institute change control on any project that is nearing completion; to do otherwise is to invite disruption, churn, and instability. This is not a question of trust, or of enabling contributions from a diverse group. What worked well early in the JSR's history won't necessarily work well as we try to complete it. It's true that commits can be rolled back, but that's an inefficient -- and potentially contentious -- way to do change control. I'd like to see things discussed and agreed before a change is committed, rather than after.

I'm mindful of the potential for me to become a bottleneck if I have to approve every change, and I'll make every effort to ensure that doesn't happen. Ultimately, while this may slow things down slightly, it's a pretty small change from the existing process -- people were already submitting PRs, the only change is who approves them -- and it will be a net win if it keeps the code stable and moving in the right direction.

One last point -- I'm not sure exactly what the rules are for repos under the javaee organization at GitHub, but I believe that all commits must be done via PR, must be approved by the spec lead, or a designate who is a member of the javaee organization, and may also be made contingent on passing some suite of tests. So the process we're adopting now is pretty close to what we'll see when the repos are migrated.

Best Regards,

Will


On 05/31/2017 08:08 AM, Ivar Grimstad wrote:


On Wed, May 31, 2017 at 12:18 PM Arjan Tijms <arjan.tijms@...> wrote:
Will,

On Wed, May 31, 2017 at 3:11 AM, Will Hopkins <will.hopkins@...> wrote:
I plan to keep the spec and api repos locked down until we're done. 

I don't think this is wise. We still have a sizeable body of work to do.

JSR 372 (JSF) and JSR 375 flourished because the spec leads did exactly the opposite: give the EG or at least some members write access. That way the JSR could continue in both presence and absence of the spec leads.

I dare to say that both JSRs would not exist anymore at this point if it hadn't been for that single decision.

Totally agree! It is just to look at the commit history to see that there is a limited number of contributors. Shutting them off, Arjan in particular, will not benefit the progress of this JSR.
 

 
We'll probably need to establish change control for the soteria repo, too, in the not-too-distant future.

The Soteria repo is already under version control, as are the spec and api repos. Since its version control anything can be reverted anyway.

I strongly believe you should trust selected members of the EG (who have proved to commit well) for not doing any rash commits that haven't been discussed and for which there has not been any consensus.

+1
All EG members have signed the JSPA, and that should suffice for contributions to the spec.
And regarding Soteria, the CONTRIBUTING.md file require the OCA to be signed. 

What you could do is to restrict access to the the repo under the Java EE organization, but keep the secuity-spec org open to the EG members that have signed the agreements.
 

Kind regards,
Arjan Tijms



 

Will


On 05/30/2017 06:29 PM, Arjan Tijms wrote:
Hi,

I noticed that the PRD has been published (thanks for that!), but that write access has not been restored for the Java EE Security API and spec repos.

Would be great if that access can be restored before long ;)

Kind regards,
Arjan Tijms

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

--

Java Champion, JCP EC/EG Member, JUG Leader


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


Re: Discussion: SecurityContext

Arjan Tijms
 

Hi,

On Wed, May 31, 2017 at 6:33 PM, reza_rahman <reza_rahman@...> wrote:
It is indeed a shame we didn't do more to step away from EJB in Java EE 7 and Java EE 8. One thing I was hoping would come out of this JSR is interceptor versions of @RolesAllowed, etc.

Absolutely, still not sure how something relatively simple as @RolesAllowed did not get in. Contributing factors were of course low amount of resources, time spend on other things including things that eventually did not get in (like the authorization rules), and some confusion about nothing new that could be added anymore even before the EDR was published.

RoleMapper, as mentioned, is another thing that I really wanted to get in, and simple (CDI) events like AuthenticatedEvent and LoggedOutEvent etc.

Kind regards,
Arjan Tijms

 

-------- Original message --------
From: Arjan Tijms <arjan.tijms@...>
Date: 5/31/17 12:20 PM (GMT-05:00)
Subject: Re: [javaee-security-spec] Discussion: SecurityContext

Hi,

I think if we split out we're basically undoing what the SecurityContext is aiming for; a one step entry point. Splitting things out has already been done. That's the JAX-RS SecurityContext, and the EJB SessionContext and what have you.

hasAccessToWebResource with a generic hasAccessToResource does sound nice, but don't forget that hasAccessToWebResource can also be called from other "containers".

JAX-RS is indeed not its own container. I have to double check, but I think in Java EE it must work with Servlet, and only outside Java EE is it allowed to build on something else (which is practice as far as I know has never really happened, apart from some very experimental code).

The entire idea of a container in the traditional sense is also fading away largely, so I'm not sure we really have to design for that tbh. EJB should eventually be completely replaced by CDI + various interceptors. Shame not more steps for that were taken this cycle.

There is the concept of security inflow though. A Java EE server can be entered via a JCA connector as well, of which the JMS connector tied to a MDB is a specific case. JCA has some interested security aspects as well, and even uses some JASPIC types.

Kind regards,
Arjan Tijms




On Wed, May 31, 2017 at 6:03 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

If this needs to be changed, I'd go for a mixed approach:
- On one hand, the split into a generic base+container specific classes is a flexible idea, but has the potential problem that Arjan explained: users in need of multiple container specific classes. Forcing them to inject multiple security contexts would be very uggly.
- On the other hand, the "generic methods" approach usually ends in too abstract solutions that are hard to use.

But what if we add a new hasPermission(Permission) method to a base SecurityContext...

public class SecurityContext {
    public boolean hasPermission(Permission permission) {
         // ...
    }
}


And Servlet specific features are moved to a new ServletSecurityContext:

public class ServletSecurityContext extends SecurityContext {
        public boolean hasAccessToWebResource(String url, String ...methods) {
            return hasPermission(new WebResourcePermission(url, methods));
        }
}


This would reduce the need for the container specific classes by providing generic enough features on the base SecurityContext, while the specific ones will be simpler to use.

What do you all think about this?


More responses inline:

On Wed, May 31, 2017 at 3:38 AM, Will Hopkins <will.hopkins@...> wrote:
I'd like to start a thread to discuss some issues related to SecurityContext.

The first, and most important, in my view, is how it's structured. I originally understood SecurityContext to be an API that was available everywhere (or at least in most containers), providing a set of common APIs that would be useful/usable everywhere. However, it now has a number of Servlet-specific methods on it.

I'm not against having container-specific functionality. We want this to be useful, and different containers have different security needs/behaviors. But as it stands now, the implementation is inelegant, at the very least. We want things to be simple and useful, but that doesn't mean we shouldn't follow OOP practices.

I think SecurityContext should either be refactored into a base/abstract class containing truly common methods, and container-specific sub-classes for container-specific behavior, or we should make the existing methods generic enough that they are applicable everywhere.

The latter approach involves substantially more change, obviously, but the idea would be to, e.g., write a generic hasAccessToResource(Resource r) method to replace the existing hasAccessToWebResource() methods. We could consider leaving authenticate the way it is, since it would be much harder to provide in a generic way.

Personally, I like the base-class/sub-class better -- it's simpler to achieve, and allows for container-specific behaviors. It requires little of developers other than being aware of what container their code is running in, if they want to use container-specific behavior. It's still essentially a common interface, but where we have container-specific behavior it's implemented in an OOP way.

Another issue is somewhat related. As currently spec'd, SecurityContext is REQUIRED only in servlet and ejb containers, but containers MAY provide it in other containers. There has been feedback that it should be available in all containers. I'm open to having it in more containers, but I think the set of containers needs to be enumerated, and for each enumerated container there needs to be a known, portable way to implement the required functionality, and an implementation in soteria. Otherwise, we're just imposing a somewhat arbitrary (all containers), and potentially difficult, implementation on container vendors.
I understand.

 Btw, what's the full list of Java EE Containers? The Java EE tutorial taks about four of them:
- EJB container
- Servlet container
- Application client container
- Applet container

JAX-RS for example is not listed as a container, but I'd expect the SecurityContext to work there. Of course, the majority of JAX-RS implementations are built on top of a Servlet, but I don't know if it is mandated to work that way when running on Java EE. I'm not sure if JAX-WS is in a similar situation.

 

Anybody want to sign up to enumerate the containers, and figure out which methods make sense in which containers? The only one that seems truly universal is getCallerPrincipal().

Thanks,

Will

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

Regards,




Re: Discussion: SecurityContext

reza_rahman@...
 

It is indeed a shame we didn't do more to step away from EJB in Java EE 7 and Java EE 8. One thing I was hoping would come out of this JSR is interceptor versions of @RolesAllowed, etc.

-------- Original message --------
From: Arjan Tijms <arjan.tijms@...>
Date: 5/31/17 12:20 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] Discussion: SecurityContext

Hi,

I think if we split out we're basically undoing what the SecurityContext is aiming for; a one step entry point. Splitting things out has already been done. That's the JAX-RS SecurityContext, and the EJB SessionContext and what have you.

hasAccessToWebResource with a generic hasAccessToResource does sound nice, but don't forget that hasAccessToWebResource can also be called from other "containers".

JAX-RS is indeed not its own container. I have to double check, but I think in Java EE it must work with Servlet, and only outside Java EE is it allowed to build on something else (which is practice as far as I know has never really happened, apart from some very experimental code).

The entire idea of a container in the traditional sense is also fading away largely, so I'm not sure we really have to design for that tbh. EJB should eventually be completely replaced by CDI + various interceptors. Shame not more steps for that were taken this cycle.

There is the concept of security inflow though. A Java EE server can be entered via a JCA connector as well, of which the JMS connector tied to a MDB is a specific case. JCA has some interested security aspects as well, and even uses some JASPIC types.

Kind regards,
Arjan Tijms




On Wed, May 31, 2017 at 6:03 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

If this needs to be changed, I'd go for a mixed approach:
- On one hand, the split into a generic base+container specific classes is a flexible idea, but has the potential problem that Arjan explained: users in need of multiple container specific classes. Forcing them to inject multiple security contexts would be very uggly.
- On the other hand, the "generic methods" approach usually ends in too abstract solutions that are hard to use.

But what if we add a new hasPermission(Permission) method to a base SecurityContext...

public class SecurityContext {
    public boolean hasPermission(Permission permission) {
         // ...
    }
}


And Servlet specific features are moved to a new ServletSecurityContext:

public class ServletSecurityContext extends SecurityContext {
        public boolean hasAccessToWebResource(String url, String ...methods) {
            return hasPermission(new WebResourcePermission(url, methods));
        }
}


This would reduce the need for the container specific classes by providing generic enough features on the base SecurityContext, while the specific ones will be simpler to use.

What do you all think about this?


More responses inline:

On Wed, May 31, 2017 at 3:38 AM, Will Hopkins <will.hopkins@...> wrote:
I'd like to start a thread to discuss some issues related to SecurityContext.

The first, and most important, in my view, is how it's structured. I originally understood SecurityContext to be an API that was available everywhere (or at least in most containers), providing a set of common APIs that would be useful/usable everywhere. However, it now has a number of Servlet-specific methods on it.

I'm not against having container-specific functionality. We want this to be useful, and different containers have different security needs/behaviors. But as it stands now, the implementation is inelegant, at the very least. We want things to be simple and useful, but that doesn't mean we shouldn't follow OOP practices.

I think SecurityContext should either be refactored into a base/abstract class containing truly common methods, and container-specific sub-classes for container-specific behavior, or we should make the existing methods generic enough that they are applicable everywhere.

The latter approach involves substantially more change, obviously, but the idea would be to, e.g., write a generic hasAccessToResource(Resource r) method to replace the existing hasAccessToWebResource() methods. We could consider leaving authenticate the way it is, since it would be much harder to provide in a generic way.

Personally, I like the base-class/sub-class better -- it's simpler to achieve, and allows for container-specific behaviors. It requires little of developers other than being aware of what container their code is running in, if they want to use container-specific behavior. It's still essentially a common interface, but where we have container-specific behavior it's implemented in an OOP way.

Another issue is somewhat related. As currently spec'd, SecurityContext is REQUIRED only in servlet and ejb containers, but containers MAY provide it in other containers. There has been feedback that it should be available in all containers. I'm open to having it in more containers, but I think the set of containers needs to be enumerated, and for each enumerated container there needs to be a known, portable way to implement the required functionality, and an implementation in soteria. Otherwise, we're just imposing a somewhat arbitrary (all containers), and potentially difficult, implementation on container vendors.
I understand.

 Btw, what's the full list of Java EE Containers? The Java EE tutorial taks about four of them:
- EJB container
- Servlet container
- Application client container
- Applet container

JAX-RS for example is not listed as a container, but I'd expect the SecurityContext to work there. Of course, the majority of JAX-RS implementations are built on top of a Servlet, but I don't know if it is mandated to work that way when running on Java EE. I'm not sure if JAX-WS is in a similar situation.

 

Anybody want to sign up to enumerate the containers, and figure out which methods make sense in which containers? The only one that seems truly universal is getCallerPrincipal().

Thanks,

Will

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

Regards,



Re: SecurityContext - downcasting getCallerPrincipal()

Arjan Tijms
 

Hi,

On Wed, May 31, 2017 at 6:16 PM, Will Hopkins <will.hopkins@...> wrote:
  • Is it OK to specify that a HAM/SAM developer an put any other Principals it wants into the Subject, but that those principals are _in_addition_ to the container's caller/group principals (which are added by handling CallerPrincipalCallback/GroupPrincipalCallback)? Note that a HAM/SAM would not be *required* to add it's own principals, since caller and group principals should be, by definition, minimally sufficient to support native (including JACC) authorization in any container.

The Subject, for the moment, is just a bag of principals. What's being put in there is, again for the moment, not the concern of JSR 375.

There's only 2 concerns really:

1. The HttpAuthenticationMechanism can use HttpMessageContext#notifyContainerAboutLogin(new MyPrincipal("myName");
2. The SecurityContext.getCallerPrincipal allows for getting MyPrincipal back.

---

How the container stores that in the Subject is not JSR 375's concern, and how the container manages to make MyPrincipal available from SecurityContext.getCallerPrincipal is also not its concern. Just like CDI also delegates this implementation to the CDI-Container integration code.

The Principal that WebLogic internally uses doesn't matter, and generic JACC code cannot make assumptions about what's in the Subject anyway, since neither Caller Principals, Groups or Group to Role mapping wrt the Subject are specified today.

There's 1 exception... and that's when the JASPIC AuthModule and the JACC authentication provider know each other, and JASPIC has forced, via some unspecified  configuration, that indeed the Principal that JASPIC sets has to be present in the Subject. Which is why I additionally mentioned the standardisation of at least this currently mandated but unspecified configuration.

But eventually I'd like to go to a standardised group to role mapper and a standardised subject reader. This was in scope for JSR 375, but we didn't get to it. I wouldn't be averse to still starting the effort for that now, as it would also help with this current issue.

Kind regards,
Arjan Tijms




 
  • Is it OK to then specify that the way an application gets access to principals is by:
    • For the container caller principal, call SecurityContext.getCallerPrincipal()
    • For application principals, call either (or both) of SecurityContext.getPrincipalByType() or SecurityContext.getSubject().getPrincipals()?
I think this model satisfies the needs both for container implementations and for HAM/SAM/application developers, allowing all principals to exist natively within the Subject, and enabling co-existence/container integration without requiring any "magic" (like wrapping principals).

If we're agreed on the model, then all we need to do is ensure the that HAM/authenticate() interfaces support it, and decide on which methods (getPrincipalByType, getSubject) we want to add to SecurityContext.

Kind Regards,

Will

On 05/31/2017 11:39 AM, Werner Keil wrote:
Unlike more generic cases like JPA, Bean Validation, etc. the return type could be more 
<T extends Principal> unwrap(Class<T>) or another method name. 

"LieGrue" just stands for "Liebe Grüße" or "Kind Regards", thus Mark could also write "KiRe" for non German speakers ;-)

Werner

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



Re: Discussion: SecurityContext

Mark Struberg
 

Yes sorry, didn't git it that there are 2 Threads which are coverying very similar - albeit different - things.

LieGrue,
strub

Am 31.05.2017 um 18:22 schrieb Guillermo González de Agüero <z06.guillermo@gmail.com>:

Hi Mark,

The need for the custom principal is clear to me ;)

My comments were just regarding Will proposal to refactor the SecurityContext class.


Regards,

Guillermo González de Agüero

Guillermo González de Agüero

On Wed, May 31, 2017 at 6:14 PM, Mark Struberg via Groups.Io <struberg=yahoo.de@groups.io> wrote:
No, this would not remove the need for a customer specific Principal imo.

Permissions alon are _not_ enough in most real world cases.

Again, think about a multi tenant system etc.

LieGrue,
strub

Am 31.05.2017 um 18:03 schrieb Guillermo González de Agüero <z06.guillermo@gmail.com>:

Hi,

If this needs to be changed, I'd go for a mixed approach:
- On one hand, the split into a generic base+container specific classes is a flexible idea, but has the potential problem that Arjan explained: users in need of multiple container specific classes. Forcing them to inject multiple security contexts would be very uggly.
- On the other hand, the "generic methods" approach usually ends in too abstract solutions that are hard to use.

But what if we add a new hasPermission(Permission) method to a base SecurityContext...

public class SecurityContext {
public boolean hasPermission(Permission permission) {
// ...
}
}


And Servlet specific features are moved to a new ServletSecurityContext:

public class ServletSecurityContext extends SecurityContext {
public boolean hasAccessToWebResource(String url, String ...methods) {
return hasPermission(new WebResourcePermission(url, methods));
}
}

This would reduce the need for the container specific classes by providing generic enough features on the base SecurityContext, while the specific ones will be simpler to use.

What do you all think about this?


More responses inline:

On Wed, May 31, 2017 at 3:38 AM, Will Hopkins <will.hopkins@oracle.com> wrote:
I'd like to start a thread to discuss some issues related to SecurityContext.

The first, and most important, in my view, is how it's structured. I originally understood SecurityContext to be an API that was available everywhere (or at least in most containers), providing a set of common APIs that would be useful/usable everywhere. However, it now has a number of Servlet-specific methods on it.

I'm not against having container-specific functionality. We want this to be useful, and different containers have different security needs/behaviors. But as it stands now, the implementation is inelegant, at the very least. We want things to be simple and useful, but that doesn't mean we shouldn't follow OOP practices.

I think SecurityContext should either be refactored into a base/abstract class containing truly common methods, and container-specific sub-classes for container-specific behavior, or we should make the existing methods generic enough that they are applicable everywhere.

The latter approach involves substantially more change, obviously, but the idea would be to, e.g., write a generic hasAccessToResource(Resource r) method to replace the existing hasAccessToWebResource() methods. We could consider leaving authenticate the way it is, since it would be much harder to provide in a generic way.

Personally, I like the base-class/sub-class better -- it's simpler to achieve, and allows for container-specific behaviors. It requires little of developers other than being aware of what container their code is running in, if they want to use container-specific behavior. It's still essentially a common interface, but where we have container-specific behavior it's implemented in an OOP way.

Another issue is somewhat related. As currently spec'd, SecurityContext is REQUIRED only in servlet and ejb containers, but containers MAY provide it in other containers. There has been feedback that it should be available in all containers. I'm open to having it in more containers, but I think the set of containers needs to be enumerated, and for each enumerated container there needs to be a known, portable way to implement the required functionality, and an implementation in soteria. Otherwise, we're just imposing a somewhat arbitrary (all containers), and potentially difficult, implementation on container vendors.
I understand.

Btw, what's the full list of Java EE Containers? The Java EE tutorial taks about four of them:
- EJB container
- Servlet container
- Application client container
- Applet container

JAX-RS for example is not listed as a container, but I'd expect the SecurityContext to work there. Of course, the majority of JAX-RS implementations are built on top of a Servlet, but I don't know if it is mandated to work that way when running on Java EE. I'm not sure if JAX-WS is in a similar situation.



Anybody want to sign up to enumerate the containers, and figure out which methods make sense in which containers? The only one that seems truly universal is getCallerPrincipal().

Thanks,

Will

--
Will Hopkins | WebLogic Security Architect |
+1.781.442.0310

Oracle Application Development
35 Network Drive, Burlington, MA 01803




Regards,

Guillermo González de Agüero

[1] https://docs.oracle.com/javaee/7/tutorial/overview004.htm




581 - 600 of 736