Hi Will,
Thanks, I saw there was also another empty repository added, but unless the
spec or API moved there, good to know.
Regards,
Werner
On Fri, Feb 3, 2017 at 5:33 PM, Will Hopkins <will.hopkins_at_oracle.com>
wrote:
> 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?
>
> 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>
> wrote:
>
>> Hi,
>>
>> On Thu, Feb 2, 2017 at 6:32 AM, Rudy De Busscher <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>
>>> 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 <%28781%29%20442-0310>
>>>> Oracle Cloud Application Foundation
>>>> 35 Network Drive, Burlington, MA 01803
>>>>
>>>>
>>>
>>
>
> --
> Will Hopkins | Platform Security Architect | +1.781.442.0310 <+1%20781-442-0310>
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>