Will/all,
I saw the split between API and Spec. What exactly was the reason to call
the API repo
https://github.com/javaee-security-spec/api-code rather than
just "api"? No real problem, just noticed "soteria" is not called
"soteria-code" either ;-)
Regards,
Werner
On Fri, Feb 3, 2017 at 5:44 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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-secu
>> rity-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
>>
>>
>