Date   

Re: Moving to Java EE Github?

Arjan Tijms
 

I share Will's concern a little here. Perhaps a copy instead of transfer is saver. Keep the existing repos as a mirror (in the title of the repos, clearly notice it are mirrors).

When after some time the mirror is not needed anymore we can delete it.

Kind regards,
Arjan Tijms


Re: Prepare for Proposed Final Draft

Rudy De Busscher
 

Hi,

Thursday is the only option for me, Friday I'm unavailable.

Best regards
Rudy

On 5 July 2017 at 18:33, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I'm booked full for Thursday, but Friday would work. 20:00 CEST is perfect.

Kind regards,
Arjan Tijms

On Wednesday, July 5, 2017, Ivar Grimstad <ivar.grimstad@...> wrote:
2:00pm EST (or EDT now) == 8:00pm CEST, or 20:00 as we would say it :)
Thursday works fine for me.

Ivar

On Wed, Jul 5, 2017 at 5:34 PM Werner Keil <werner.keil@...> wrote:
2pm Pacific?

At least for me that would work. Thursday maybe even a bit better, but Friday might also work.

Werner
--

Java Champion, JCP EC/EG Member, JUG Leader



Re: Moving to Java EE Github?

Will Hopkins
 

Is that something you tried when migrating other JSRs? My chief concern is a catastrophic failure (loss of the repo or some part of it) if the transfer doesn't go through, due to permissions problems, or because there's something different about the javaee organization compared to other organizations at github (because it's a corporate org).

Will

On 07/05/2017 11:14 AM, Werner Keil wrote:
If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.

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


Re: Prepare for Proposed Final Draft

Arjan Tijms
 

Hi,

I'm booked full for Thursday, but Friday would work. 20:00 CEST is perfect.

Kind regards,
Arjan Tijms


On Wednesday, July 5, 2017, Ivar Grimstad <ivar.grimstad@...> wrote:
2:00pm EST (or EDT now) == 8:00pm CEST, or 20:00 as we would say it :)
Thursday works fine for me.

Ivar

On Wed, Jul 5, 2017 at 5:34 PM Werner Keil <werner.keil@...> wrote:
2pm Pacific?

At least for me that would work. Thursday maybe even a bit better, but Friday might also work.

Werner
--

Java Champion, JCP EC/EG Member, JUG Leader


Re: Prepare for Proposed Final Draft

Ivar Grimstad
 

2:00pm EST (or EDT now) == 8:00pm CEST, or 20:00 as we would say it :)
Thursday works fine for me.

Ivar

On Wed, Jul 5, 2017 at 5:34 PM Werner Keil <werner.keil@...> wrote:
2pm Pacific?

At least for me that would work. Thursday maybe even a bit better, but Friday might also work.

Werner

--

Java Champion, JCP EC/EG Member, JUG Leader


Re: Prepare for Proposed Final Draft

Werner Keil
 

2pm Pacific?

At least for me that would work. Thursday maybe even a bit better, but Friday might also work.

Werner


Re: Prepare for Proposed Final Draft

Will Hopkins
 

Can people join a meeting sometime this week? What time would be good for people?

The last meeting was at 2:00pm EST on a Friday? Is that a good time? Would Thursday at 2:00pm work?

Will

On 06/23/2017 12:05 PM, Werner Keil wrote:
Sounds like a good idea. 
Another hangout or more if necessary.

Regards,
Werner

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


Re: Moving to Java EE Github?

Werner Keil
 

If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.


Re: Moving to Java EE Github?

Will Hopkins
 

Either way, I think your assistance would be helpful.

Do you happen to know whether the "move" capability in GitHub, which allows a repo to be transferred from one organization to another will work? That would probably be the safest way to move while preserving issues and all the history. For the "security-spec" repo, the java.net issues have been migrated to security-spec under the javaee organization already, so for that repo we might need to use clone, but I'd want someone more experienced with git to verify the correct procedure to preserve all the commit history, branches, labels, etc.

Thanks,

Will

On 07/03/2017 04:24 PM, Will Hopkins wrote:
What do you think about moving it after the PFD is published?

On 07/03/2017 05:08 AM, Werner Keil wrote:
Hi,

At least before Proposed Final Draft I was wondering, if a move to the official GitHub organization for Java EE https://github.com/javaee was planned any time soon?
If it isn't done now, then most likely all documents including the Spec etc. will have to refer to the existing GitHub organization and that needs to remain until e.g. a new Security JSR (follow up to 375) arises at some later point.

Moving it after it went Final would be confusing. So let's either try to do this now, or stay there till another JSR comes up for Security under Java EE 9 or later.

I assisted most of this transition for JSR 374 (JSON-P) so happy to help if given the right credentials and ability. I'm sure, others like Rudy or Arjan are equally happy to to help if Will and his colleagues at Oracle are busy with other duties or things only they can do at the moment (like writing the TCK;-)

Kind Regards,
Werner

-- 
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: Discussion: SecurityContext

Will Hopkins
 

So, where does that leave us in terms of either:
  • Separating out the generic SecurityContext interface and methods from the servlet-specific methods (i.e., using "interface ServletSecurityContext extends SecurityContext"); or,
  • Changing the signatures of the servlet-specific methods (as many as possible) to be generic so they could be useful in multiple containers?
I think it's probably too late to be changing signatures, and that wouldn't work for the authenticate() method anyway.

I do think it's pretty straightforward to separate out the generic and servlet-specific methods into separate interfaces, and I don't think doing so adds any significant complexity, or interferes with ease of use -- unless you're doing something servlet-specific, you can use SecurityContext anywhere, and, if you are doing something servlet-specific, referencing a servlet-specific type (ServletSecurityContext) doesn't seem like an unreasonable burden. We would still retain the benefits of common code and common signatures for the common methods. A monolithic interface that includes methods not usable in the "current" container imposes its own complexity and usability issues, IMO.

That said, I'm OK leaving SecurityContext the way it is, if that's the consensus of the EG. Just want to close on the issue.

Regards,

Will

On 06/01/2017 07:53 PM, Arjan Tijms wrote:
Hi,

Thinking about this a little more and reading your replies, I'm convinced now that we should indeed not make this multi-module, but just keep it to the same module only.

Thanks for letting me see this.

Kind regards,
Arjan Tijms




On Thu, Jun 1, 2017 at 11:45 PM, Will Hopkins <will.hopkins@...> wrote:
As a general rule, my feeling is that the owner of the resource is the entity that should authorize access to it. So that if you want to test access to, e.g., an external email module, you need to ask that module if the caller has access, rather than try to determine on your own based on some policy provisioned into your app. Evaluating policy across application contexts might be trivial for some authorization subsystems (assuming a common body of authorization policy), but might be difficult for others.


On 06/01/2017 05:37 PM, Bill Shannon wrote:
Using this across modules would introduce a tight coupling that probably isn't desirable.  Roles really do seem like a better approach in that case.  Or the module could provide an API that could be called to determine if the caller has "admin permission" or whatever needs to be tested to influence the behavior of the calling module.

Having a way for a web module to test whether access is allowed to one of the resources of that same web module seems fine.

Arjan Tijms wrote on 05/31/2017 04:34 PM:
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




 






-- 
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: SecurityContext - downcasting getCallerPrincipal()

Will Hopkins
 



On 06/29/2017 02:41 PM, Arjan Tijms wrote:
Hi Will,

That all sounds good. Thx!

A few remarks though:

All servers except WebLogic in fact do return the exact Principal that one puts into the CallerPrincipalCallback from HttpServletRequest#getUserPrincipal(). This may be something to take into account for the terminology.
Good point; I'll give that some thought. At this point, though, I'm still leaning towards leaving it as caller principal given the JASPIC language.

As for an extra method in HttpMessageContext; this could be an option, but if one puts a string based principal in then that could also signal that the container specific principal is to be used. Likewise one could put in the exact type that the container uses.
Right; makes sense. And there would only be a need for two principals in the Subject if the application-supplied and container-specific types were different.

 I just looked more carefully, though, and noticed that caller parameter passed to notifyContainerAboutLogin(), if not String, is always a CallerPrincipal, or a CredentialValidationResult that can only return CallerPrincipal.

How can a HAM provide an application-specific Principal type (that does not extend CallerPrincipal)? Should we change the signature with CallerPrincipal to take Principal instead? Or add another method with a Principal parameter?

Along similar lines is it reasonable to assume, when the caller is provided as CallerPrincipal, that the application doesn't care about the actual type (as CallerPrincipal is generic), and use only the container-specific principal type without also including the CallerPrincipal?

Although it's perhaps obvious to us, it may be a good idea to clarify that both application and container principal are related in the fact that calling getName on them (the one method from Principal) returns the same string (e.g. "Reza").
Agreed. I'll add language to that effect.

It may be a good idea (but not strictly needed) to specify that class Javax...CallerPrincipal is always supported to request from SecurityContext. If the ham didn't explicitly provided this type it would then be defined as a CallerPrincipal instance with as return value from getName() the same string value again that Principal.getName() returns of the Principal that was provided.
I'm OK with that. I probably wouldn't add it unless the EG felt strongly -- the caller could always do "new CallerPrincipal(SecurityContext.getCallerPrincipal().getName())", which might be more intuitive than going to the javadoc to determine that the method can always return CallerPrincipal -- but it seems easy and safe enough to add.

Let me know if you'd like me to add it.


Kind regards,
Arjan





On Thursday, June 29, 2017, Will Hopkins <will.hopkins@...> wrote:
Exactly. Both principals would be in the Subject. I do think there's an extra step to take, though, and that's to standardize on the terminology, and the APIs, for accessing those principals.

If we are agreed that there are, at least conceptually, two principals, then we need to know what each is called, and each will need an accessor.

I would propose that the platform principal be called the caller principal. This is mostly to maintain consistency with the JASPIC spec and the language it uses in respect to "the container's representation of the caller principal" and the behavior that existing servers have already implemented around returning that principal from, e.g., the HttpServletRequest.getUserPrincipal() method.

For the app/HAM principal, we'll either need an API that knows which principal the application put in the Subject and returns it, or (better/easier in my view), something ilke:
Set Principal SecurityContext.getPrincipalByType(Class<T> type)
Or:
// this is simpler, and would most often be sufficient, but if there were more than one
// principal of the given type, the result would be arbitrary
Principal SecurityContext.getPrincipalByType(Class<T> type)
The other aspect we need to consider is how the HAM notifies the container about the various principals. I think that can be handled pretty easily by extending HttpMessageContext.notifyContainerAboutLogin() to support an additional "application principal" parameter for the two cases where caller principal is explicitly supplied.

Will


On 06/29/2017 12:14 PM, Arjan Tijms wrote:
p.s.2

Reading this one again:

On Thu, Jun 29, 2017 at 08:28 am, Will Hopkins wrote:
Well, this is exactly the point. I'm suggesting that we declare "CallerPrincipal" and "MyPrincipal" aren't the same thing, and that notifyContainerAboutLogin() be required to handle CallerPrincipalCallback, and, if appropriate, GroupPrincipalCallback. In the case that only caller name is provided, that would result in only the container's representation of the CallerPrincipal being added to the Subject. In the case that an actual principal was provided, and it was not of the same type as the container's "native" caller principal type, it would be added to the subject _in_addition_to_ the container's caller principal.

Aren't we suggesting the same thing here actually?

Maybe there's been a little confusion about the terms, but after giving it a second look it seems the suggestions are quite identical.

Indeed, in both cases there would be an additional principal. The location of that principal is undefined by the spec. A given implementation could put it into the Subject as a second principal, could wrap it inside the existing principal, or could even store it somewhere else (TLS, request attribute, etc).

How it goes over the wire is undefined as well. I would assume most servers are capable to expand on their native principal type and allow it to have an extra field that older servers would ignore, but of course that's only an assumption.

Proprietary implementations could also provide a second call, or a second data item, which it would only send if the other remote server is recognised as a newer one, etc etc. There's a myriad of options here, but as mentioned we could for now we could make the remote case optional.

What do you think?

Kind regards,
Arjan Tijms

-- 
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: Default group to role mapping

Will Hopkins
 

Let's leave the current spec language as it is, then.

On 06/30/2017 02:42 PM, Rudy De Busscher wrote:
Hi,

In any case, for me, the group to role mapping must be configurable in a standardized way. So it is no option that it will be handled by a server application specific config.

If it is really an issue for Glassfish then we could make the value to false (when not specified) so that at least 99% of the other user can specify the value true.
But since the majority of the servers do already default mapping, I prefer to have it also by default enabled.

Regards
Rudy

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


Re: Moving to Java EE Github?

Will Hopkins
 

What do you think about moving it after the PFD is published?

On 07/03/2017 05:08 AM, Werner Keil wrote:
Hi,

At least before Proposed Final Draft I was wondering, if a move to the official GitHub organization for Java EE https://github.com/javaee was planned any time soon?
If it isn't done now, then most likely all documents including the Spec etc. will have to refer to the existing GitHub organization and that needs to remain until e.g. a new Security JSR (follow up to 375) arises at some later point.

Moving it after it went Final would be confusing. So let's either try to do this now, or stay there till another JSR comes up for Security under Java EE 9 or later.

I assisted most of this transition for JSR 374 (JSON-P) so happy to help if given the right credentials and ability. I'm sure, others like Rudy or Arjan are equally happy to to help if Will and his colleagues at Oracle are busy with other duties or things only they can do at the moment (like writing the TCK;-)

Kind Regards,
Werner

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


Re: responseUnAuthorized: rename to responseUnauthorized

Will Hopkins
 

It's merged.

On 07/03/2017 05:08 AM, Arjan Tijms wrote:
Hi,

On Monday, July 3, 2017, Werner Keil <werner.keil@...> wrote:
I assume Will or Ed are the only ones who can merge that now?

I guess so. But Ed is not really involved with the Security API, so I think practically it's only Will then.

Kind regards,
Arjan

 

Regards,
Werner

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


Re: Publishing snapshots?

Will Hopkins
 

API and RI are both building and just published snapshots for both.

On 07/03/2017 03:40 PM, Werner Keil wrote:
As long as it works either one is fine.

Every milestone release also gets mirrored to Bintray/JCenter (not sure about the java.net snapshot repo though, I have not used it for quite a while)

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


Re: Publishing snapshots?

Werner Keil
 

As long as it works either one is fine.

Every milestone release also gets mirrored to Bintray/JCenter (not sure about the java.net snapshot repo though, I have not used it for quite a while)


Re: Publishing snapshots?

Will Hopkins
 

I had hoped to have regular snapshot publishing in place by now. I'll check into what's going on. We should not be publishing anything to bintray.

On 07/03/2017 08:55 AM, Arjan Tijms wrote:
In this case though, it's just a matter of entering the bintray repo in the pom.xml of soteria again, so it can find the snapshot of API.

Currently it fails on not being able to find the API snapshot.

On Mon, Jul 3, 2017 at 2:49 PM, Werner Keil <werner.keil@...> wrote:
We cannot remove what's under
http://oss.jfrog.org/libs-snapshot/javax/security/enterprise/javax.security.enterprise-api/

Only stop deploying, but there should be deployments to another snapshot instead and Soteria as well as other artifacts (e.g. demos or independent implementations) must know which additional snapshot repos to use (only MavenCentral/Sonatype will be done by default)

Kind Regards,
Werner


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


Re: Publishing snapshots?

Arjan Tijms
 

In this case though, it's just a matter of entering the bintray repo in the pom.xml of soteria again, so it can find the snapshot of API.

Currently it fails on not being able to find the API snapshot.

On Mon, Jul 3, 2017 at 2:49 PM, Werner Keil <werner.keil@...> wrote:
We cannot remove what's under
http://oss.jfrog.org/libs-snapshot/javax/security/enterprise/javax.security.enterprise-api/

Only stop deploying, but there should be deployments to another snapshot instead and Soteria as well as other artifacts (e.g. demos or independent implementations) must know which additional snapshot repos to use (only MavenCentral/Sonatype will be done by default)

Kind Regards,
Werner



Re: Publishing snapshots?

Werner Keil
 

We cannot remove what's under
http://oss.jfrog.org/libs-snapshot/javax/security/enterprise/javax.security.enterprise-api/

Only stop deploying, but there should be deployments to another snapshot instead and Soteria as well as other artifacts (e.g. demos or independent implementations) must know which additional snapshot repos to use (only MavenCentral/Sonatype will be done by default)

Kind Regards,
Werner


Re: Publishing snapshots?

Arjan Tijms
 

It's unfortunate indeed. Maybe it was better to wait with removing bintray snapshots till the snapshots/CI that Will had in mind were actually in place.

On the short term I think I may be able to make the CI (Travis) work again by adding the bintray repo back to Soteria, so Soteria can fetch the snapshots from bintray again.

WDYT?

Kind regards,
Arjan


On Mon, Jul 3, 2017 at 1:37 PM, Werner Keil <werner.keil@...> wrote:
That's quite unfortunate. Especially for a new JSR that hopes for adoption by container vendors as soon as possible;-/
Last time it was published is over 2 weeks ago: https://maven.java.net/content/repositories/snapshots/javax/security/enterprise/javax.security.enterprise-api/1.0-b07-SNAPSHOT/

Can't say what java.net now requires to automate it after the site officially went away?
It worked well on Bintray from a CI server. Other 1.0 JSRs under Java EE 8 like JSON-B do this on a regular basis to Eclipse: https://repo.eclipse.org/content/repositories/yasson-snapshots/org/eclipse/yasson/


Kind Regards,
Werner


481 - 500 of 736