Topics

Please Review security-api Pull Request #38 ASAP


Will Hopkins
 

I've made a number of API changes as discussed during the EG call last week. I plan to submit the changes as part of the PFD submission today, so if anyone has comments please let me know ASAP.

This is not the last chance to make changes -- we can submit an updated PFD draft if necessary -- but it's far better if we don't have to.

https://github.com/javaee-security-spec/security-api/pull/38

Thanks,

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


Werner Keil
 

Looks OK from what I saw so far. The getCallerPrincipal() method name makes a bit less sense now, although the JavaDoc hits at a "calling user" so I guess that makes it acceptable, but  wondering, if this method would ever return a "more specialized" Principal in the future, or always the abstract interface?

Is there any part of the API that directly returns
https://github.com/javaee-security-spec/security-api/blob/master/src/main/java/javax/security/enterprise/CallerPrincipal.java
now?

Otherwise what justifies that concrete class to remain in the API if it is not used? It may also live in Soteria.

The PRD ballot only ends today, so unless we're under great time pressure by the  EE Umbrella to push out a PFD within a few days, we would not need to submit it immediately. If some of these late changes can be confirmed internally and a majority agrees on, then maybe it's OK with a single PFD and no updates to it.

Werner


Will Hopkins
 

I'm under pressure to submit the PFD today so that it can be up for review by Friday.

Agree with the observation about CallerPrincipal. The IdentityStore still returns CallerPrincipal (via CredentialValidationResult), but I think that's it. Arjan has made the point that it's handy to have a concrete Principal implementation, so every app doesn't have to invent its own, and I think it makes sense for IdentityStore to return a generic principal type, but I don't have strong feelings in that regard.

On 07/10/2017 10:30 AM, Werner Keil wrote:
Looks OK from what I saw so far. The getCallerPrincipal() method name makes a bit less sense now, although the JavaDoc hits at a "calling user" so I guess that makes it acceptable, but  wondering, if this method would ever return a "more specialized" Principal in the future, or always the abstract interface?

Is there any part of the API that directly returns
https://github.com/javaee-security-spec/security-api/blob/master/src/main/java/javax/security/enterprise/CallerPrincipal.java
now?

Otherwise what justifies that concrete class to remain in the API if it is not used? It may also live in Soteria.

The PRD ballot only ends today, so unless we're under great time pressure by the  EE Umbrella to push out a PFD within a few days, we would not need to submit it immediately. If some of these late changes can be confirmed internally and a majority agrees on, then maybe it's OK with a single PFD and no updates to it.

Werner

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


Werner Keil
 

Will,

I had a look at the PFD of Java EE 8 where Security is also referred, to, e.g. EE.3.3.4.2
  • isCallerInRole (SecurityContext)
  • getCallerPrincipal(SecurityContext) 
  • isCallerInRole (EJBContext) 
  • getCallerPrincipal (EJBContext) 
  • isUserInRole (HttpServletRequest) 
  • getUserPrincipal (HttpServletRequest)
So whatever changes we still come up with, once the EE 8 umbrella goes final, the API for 1.0 should also be considered feature frozen.
Luckily there's no direct reference to anything other than the JCP detail page, so moving within GitHub seems OK even after EE 8 went Final.

Werner