Hi Werner,
No, the spec is still read-only on GitHub.
I have made some changes to the org -- you and I are now the only
"Owners", and I've migrated to org to the new team semantics. The
"Members" group is now "EG Members" (to distinguish from GitHub org
members), and I removed the Owners group, since it's now replaced by org
Owner role.
I've also updated the spec-api repo to remove the api module and move
the spec module up to the top level, and also created a new "spec" repo
at GitHub with the idea of having it mirror to java.net. Now I'm looking
at the hudson job that does the syncing and wondering if it's easier to
just rename the old repos and change the sync direction. I'll have it
figured out by tonight.
Will
On 02/02/2017 05:45 AM, Werner Keil wrote:
> Hi,
>
> Especially about "Relationship to other specs", are the repositories
> bi-directional now, so a PR or push to
> https://github.com/javaee-security-spec/spec-api/tree/master/spec/src/main/doc
> would manifest, or is it still overwritten from java.net
> <http://java.net>?
>
> I can fix that (if GitHub works) because the CDI Spec in
> https://github.com/javaee-security-spec/spec-api/blob/master/spec/src/main/doc/authenticationMechanism.asciidoc
> and possibly other documents should not say JSR 346 any more but 365.
> JSR 375 not only tails 365 by ten numbers, it aims to contribute
> "something" (what we get Final in time) to Java EE 8, so the CDI
> version that's close to its own Final release would be 2.0.
>
> Kind Regards,
>
> Werner Keil
>
>
>
> On Thu, Feb 2, 2017 at 11:18 AM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> On Thu, Feb 2, 2017 at 6:32 AM, Rudy De Busscher
> <rdebusscher_at_gmail.com <mailto:rdebusscher_at_gmail.com>> wrote:
>
> Hi all,
>
> I was also thinking about the item "Relationship to other
> specs" recently.
>
> And, although we have already some nice things realized, the
> main focus is on making JASPIC easier and not relying anymore
> on container configuration.
>
> But how will we handle the authentication and authorization
> usages from within web.xml (like security constraints,
> auth-method, ... defined in web.xml) ?
>
>
> Security constraints are fully supported, as these hook into the
> same "Java EE security backbone" that JASPIC, and thus we, are using.
>
> auth-method is being overridden, so this is a little awkward. If
> you put e.g. FORM there, AND configure either a HAM or SAM (to use
> Will's abbreviations :P), then FORM is simply ignored.
>
> I'm not sure how to best get rid of that awkwardness. It would
> indeed require an update of the Servlet spec.
>
> For further integration, we could also define that the existing
> authentication mechanisms from Servlet are able to use our
> Identity Store. Technically that would mean implementing a bridge
> from a native identity store to the JSR 375 Identity Store. The
> other way around was already mentioned before I think, I bridge
> from the JSR 375 store to the native store. That way a user could
> configure a JSR 375 authentication mechanism, and then say: "use
> the natively server defined store"
>
> Kind regards,
> Arjan Tijms
>
>
>
> Will we have 2 separate ways of working (the 'old' way and the
> new one), do we integrate them (but then an update to the
> other specs like servlet, ejb, jax-rs, websocket, CDI, ... is
> required), ... ?
> best regards
> Rudy
>
>
> On 1 February 2017 at 20:05, Will Hopkins
> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>
> Third try's a charm?
>
> Experts:
>
> First of all, many thanks to Arjan for putting together
> the first draft of our spec -- it's an excellent start.
>
> I've had a look at it, and have some comments/questions
> for discussion. I think the biggest issues to resolve are
> probably:
>
> * The interaction (or lack thereof) between
> HttpAuthenticationMechanism and JASPIC.
>
> * On a similar note, what is the behavior if
> HttpAuthenticationMechanism is called both by the
> container and by application code.
>
> * How is SecurityContext integrated with containers such
> that authenticate() can know what authentication
> mechanisms are configured and getXYZ() can report the
> correct information?
>
> * Is CallerPrincipal a sufficient credential for
> IdentityStore.getGroupsByCallerPrincipal()? Can it be
> safely used when there are multiple ID stores
> configured (since the wrong groups could potentially
> be returned)?
>
> * Related: should we define CallerAttributes in addition
> to CallerGroups? Any and all comments welcome.
>
> Thanks,
>
> Will
>
> 0.0 General
>
> * Use of CDI vs. other mechanisms for accessing the
> interfaces -- I think it's reasonable to say that
> containers must use/support CDI in the ways described
> by the spec. (Am I correct that all EE Profiles that
> include servlet would also include CDI?) Is it
> worthwhile specifying that EE implementations can
> optionally choose to make the interfaces available in
> some other way (factory method, etc.)? Should we
> specify such a mechanism?
>
> 2.4 Installation
>
> * Container should be able to override ID store
> contained within app.
>
> 2.6 Validation and obtaining caller data
>
> * Should the API support other types of user attributes
> beyond groups? A generic attribute type?
>
> * What if the information in a caller principal is
> insufficient to distinguish the caller's identity (if,
> for example, the credential provided when
> authenticating included a full DN, or a duplicate
> username was disambiguated by virtue of the fact that
> the password matched)? In that case, the correct
> groups could not be determined. Should we limit the
> use of this to validate, and require the caller to
> make use of the returned groups when creating a
> subject, or retain the CredentialValidationResult?
>
> * Would overloading actually work in this case, or would
> the runtime always call validate(Credential) even if a
> Credential sub-class type is passed? Might need
> generics for this.
>
> * Last paragraph -- what if it can't, because it can't
> distinguish between two foos, or because name is
> insufficient to identify the user. Can (or should) an
> ID store support getGroupsByCallerPrincipal() for a
> CallerPrincipal not originally validated by that ID store?
>
> 2.7 Build-in Identity Store Beans
>
> * Embedded -- annotation only? No support for deploying
> a file or other mechanism? Safety of embedding
> passwords in file or in code (annotation)?
>
> * LDAP -- is annotation rich enough to support real-life
> deployment requirements?
>
> 2.8. Handling multiple identity stores
>
> * When validation fails, would it not be better to
> remember if any of the identity stores accepted the
> credential, and return INVALID instead of
> NOT_VALIDATED if any of them did?
>
> * If we have a VALID result, won't we already have the
> groupsu associated with the validate() that succeeded?
> Do we want to aggregate groups from all stores, that
> return them, or return only groups from the store that
> validated the user? I would argue for the latter.
> This issue also complicates the provision of a
> separate group lookup method when more than one id
> store is present -- what if store A has a user foo,
> but validation fails. Store B also has a user foo,
> which is validated with the supplied credential. A
> subsequent call to get groups would succeed for store
> A, but return groups for the wrong user (i.e, the
> "foo" whose credential was not validated).
>
> 3.4 Installation
>
> * It must be possible to package an
> HttpAuthenticationMechanism in an app, but can it be
> possible for server to override app-provided mechanism?
>
> * Should we define a web.xml token for indicating that
> an HttpAuthenticationMechanism is in use, similar to
> BASIC, FORM, CERT? (since the analogy is presented in
> section 3.3).
>
> 3.5 Orchestrating the authentication dialog
>
> * Does validateRequest() get called twice, then, if
> called by the container and again when the application
> calls authenticate()? Must it therefore be idempotent?
>
> * Should the ServerAuthModule's secureResponse() method
> be called if the HttpAuthenticationMechanism's is?
>
> * What happens if there is also a ServerAuthModule
> installed/configured for the app? Are both mechanisms
> invoked (it seems likely they'd interfere with each
> other)? How does, e.g., an error returned from a
> ServerAuthModule affect the subsequent invokation of
> the HttpAuthenticationMechanism?
>
> * The JASPIC spec goes into some detail about exit codes
> from validateRequest() and the subsequent behavior of
> the container in terms of returning errors vs.
> proceeding to invoke the servlet, codes that indicate
> success but a requirement to continue dialog with the
> client before invoking the servlet, etc. What should
> HAMs do? Should we specify behavior that matches
> SAMs? Different behavior?
>
> 4.0 General
>
> * How does SecurityContext determine the caller
> principal and query the roles? Is it the
> responsibility of containers to ensure the
> SecurityContext is populated with the correct
> information? Does it get the current Subject of the
> stack and use that to get the CallerPrincipal and test
> roles? Etc.
>
> 4.2 Relationship to other specs
>
> * This spec declares that the new security context
> supercedes all these other mechanisms. Should we say
> something about what the legacy behavior is, for older
> apps, and the extent to which the old and new
> mechanisms must return the same values? I.e., we
> could declare that the older mechanisms remain, for
> legacy support, but must be implemented by delegating
> to the new SecurityContext, or, at minimum, behave at
> all times as if they delegated to SecurityContext.
> (This also implies that the new SecurityContext must
> return values consistent with the older APIs.)
>
> 4.3 Testing for Caller Data
>
> * Downcasting -- to be clear, this section does not
> assume that HAM and SAM are the only possible sources
> of Caller Principals, correct? I.e., a container
> might choose to implement BASIC, FORM, and CERT using
> proprietary interfaces. Or are we suggesting that all
> containers should provide BASIC/FORM/CERT via HAM or SAM?
>
> * isCallerInRole() -- this should not be defined to map
> explicitly to a group principal in the subject;
> rather, it should map to a role in a security
> constraint, which may be mapped arbitrarily by the
> container. See, e.g., the javadoc for
> isCallerInRole/isUserInRole for
> EJBContext/HttpServletRequest.
>
>
> --
> Will Hopkins | Platform Security Architect |+1.781.442.0310 <tel:%28781%29%20442-0310>
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>
>
>
--
Will Hopkins | Platform Security Architect | +1.781.442.0310
Oracle Cloud Application Foundation
35 Network Drive, Burlington, MA 01803