Hi,
On Mon, Mar 23, 2015 at 11:33 PM, Alex Kosowski <alex.kosowski_at_oracle.com>
wrote:
> I really just meant that the container spec leads have handled security
> for their respective containers in the past, and it may not be apparent
> that our JSR EG should be advised of changes.
>
As with everything there are of course multiple ways to look at it, so I
can see your point.
Still, both JASPIC and JACC have defined security for specific containers
within Java EE, from outside the spec of that container. In this case with
"container" I'm referring to the Servlet container and EJB container, not
the entire server. In that regard, "container" is a somewhat difficult term
too, since people often use it to refer to the entire server as well.
That is why I asked the other spec leads for Security API changes. Also,
> things like @RolesAllowed were mostly defined by containers that
> implemented them. Now with JSR 375, we may be imposing container security
> requirements from outside the container.
>
As mentioned above, if we you mean with "container" here e.g. the "servlet
container", then that's not that different in my opinion as things
currently are.
> This brings up the question of integration. If JSR 375 enhances existing
> security configuration (e.g. extending @RolesAllowed), are we changing the
> container or extending the container? For example, is JSR 375 inherently
> extending the Servlet spec if we add security configuration for servlets?
> Or is JSR 375 a required extension?
>
So JASPIC had the exact same issue. It asks several containers (Servlet and
EJB) to do things in a certain way. The way the spec is currently defined
is that the JASPIC Servlet Profile is an optional extension for standalone
Servlet implementations or Servlet implementations that are used in a Java
EE Web Profile product, and a mandatory extension for Servlet
implementations that are used in a Java EE Full profile product.
The spec references are bi-directional. JASPIC refers to the Servlet spec
when describing its Servlet Profile, while the Servlet spec *recommends*
that Servlet implementations use the JASPIC interfaces for custom
authentication mechanisms.
There's something similar with JACC, where JACC asks Servlet containers as
well as EJB containers among others to make their authorization rules
available as collections of Permission instances.
> I guess it really depends on what changes we specify. Really just thinking
> out loud...
>
I hear you, and I agree.
There's a question if we indeed need to ask those containers or specs to do
anything in a specific way, but that's defined in our spec. Role mapping
may come to mind, depending on how its defined exactly (does it need syntax
in web.xml?) and if we define the standard "authentication/identity
stores", then we of course would like that the existing authentication
mechanisms in Servlet like FORM, BASIC etc would delegate to these. In that
last case we might not so much extend Servlet, but ask Servlet to support
us/have us as a dependency (but it's a thin line).
An easier thing perhaps is if we can get away with other specs making
certain APIs or SPIs available, but basically just ask them as any
community member could do without any specific spec connection. E.g. for
JSF I asked the Servlet EG to expose the Servlet mapping type (see
https://java.net/jira/browse/SERVLET_SPEC-73). If they indeed implement
that, it's just a feature that anyone can use and spec-wise doesn't have
any JSF connection.
A bit related to this is to ask specs NOT to do any new security things of
their own. E.g. the JAX-RS EG was discussing extending some of their
security APIs, and I asked them (as a community member) to consider not
doing this, but just taking advantage of whatever the security EG produces.
Furthermore, our spec can provide easy of use abstractions for say JASPIC,
without necessitating any JASPIC spec change. Going again to JSF, it's just
like JSF builds on top of Servlet, but spec-wise isn't a Servlet spec
extension.
Finally, there's a LOT any spec can now do using the universal extension
mechanisms provided by CDI and the Interceptor spec. One of the CDI guys
once said that with CDI extensions the community can build their own next
version of Java EE, but that actually holds for Java EE specs themselves
too.
For @RolesAllowed, it was discussed before on e.g. the CDI EG list to
implement this or a similar annotation using CDI and/or the Interceptor
spec.
But CDI mainly wants to provide the building blocks for other specs, not
contain too much higher-level functionality itself (e.g. just like
@Transactional builds on CDI, but is placed inside the JTA spec, not inside
CDI which would risk making CDI simply another EJB spec). Therefor such new
implementation of @RolesAllowed would be perfect to place in the Security
API. Any CDI managed bean in the entire platform could then use it.
The only thing to really take into account here would be that the
collection of roles to test against (i.e. those owned by the authenticated
identity) would need to be the same for the existing EJB based
@RolesAllowed and the new CDI based @RolesAllowed. This is an issue with a
couple of the existing solutions that implement security completely using
CDI and/or Servlet Filters. They often make the roles only available to
their own APIs, but not to the existing @RolesAllowed. Via a ServletRequest
wrapping trick you can make those roles available to
HttpServletRequest#isUserInRole but IMHO it's a bit of hack.
Kind regards,
Arjan Tijms
>
>
>
> In other cases, an app starts small (as a prototype) and I want to
> define security within the app to get easily started. But eventually the
> app grows and needs to be incorporated into a larger infrastructure so it
> needs to change to security being defined at the container side.
>
> Therefor I think it's really important that we keep supporting both use
> cases.
>
> We really have to for backward compatibility.
>
>
> Thanks,
> Alex
>
>
> On 3/21/15 7:41 AM, arjan tijms wrote:
>
> Hi
>
> On Sat, Mar 21, 2015 at 3:42 AM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
>
>> Hi Rudy,
>>
>> Do we know (do you get notified, CC'ed, ...) from the other Expert groups
>> what there plans are around security? As I can read here that for the new
>> servlet spec the want to promote the role of JASPIC. This is of course
>> very important for us.
>>
>> I will occasionally get notified of security related changes.
>>
>
> I think that security does not really exists on its own. It hooks into a
> number of locations. We've mainly been talking about web concepts here,
> since that's often the first and most logical thing on everyone's mind, but
> there's also the EJB container and the JCA one that need to be secured.
> Basically everywhere where there's an external connection coming into the
> system.
>
> It's however specifically JAX-RS and Servlet that have been talking
> about concrete security changes for Java EE 8.
>
>
>
>> However, JSR 375 is new, and container security has traditionally been
>> handled within the container, so our JSR is a bit of a cultural shift of
>> sorts.
>>
>
> I don't know if that's necessarily fully the case.
>
> From one point of view everything in Java EE is considered to be
> "container provided". E.g. JSF, CDI, JPA are all container services. Unless
> we propose that the binary result of this JSR is a .jar that has to be
> downloaded separately and always has to be included in WEB-INF/lib or
> EAR/lib, it's maybe not such a big cultural shift in that regard (but I
> think you likely were not referring to this ;))
>
> As to the other definition of "container security", where it means that
> security is configured in a proprietary way at the container side (e.g. by
> using standalone.xml for JBoss), then this has traditionally indeed mostly
> been the case.
>
> However, Servlet has always given the user the choice to configure the
> auth-method from within the application. And since JASPIC it has been
> possible to provide authentication mechanisms including the authentication
> store (realm/repo/authenticator) fully from within the application.
>
> I've used this in pretty much all my Java EE applications that I've
> build since ~2009 (Java EE 6), so the cultural shift had already started
> well over 5 years ago ;)
>
> While I'm a big fan of being able to configure and define things from
> within the application (not just security, but datasources, jms
> destinations, etc as well), I do like to stress that the ability to
> configure those things at the container side is ALSO important. That's the
> beauty of Java EE now, you can transparently switch between application
> level configuration and container level configuration. Depending on your
> use case you choose a method, and if the use case changes it's a small
> change in the code to switch.
>
> E.g. if I operate a single web site, where external users register and
> especially where I deploy one application to one application server, I
> always want to configure security from within the application.
>
> However, when I need to integrate an existing Java EE application in a
> corporate intranet, almost without exception I want to configure security
> (and datasources, etc) at the container side.
>
> In other cases, an app starts small (as a prototype) and I want to
> define security within the app to get easily started. But eventually the
> app grows and needs to be incorporated into a larger infrastructure so it
> needs to change to security being defined at the container side.
>
> Therefor I think it's really important that we keep supporting both use
> cases.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>>
>> I recently sent an email to the other Oracle EE spec leads requesting a
>> summary of Security API changes proposed in each of their respective specs.
>> I will compile and forward the responses.
>>
>> Thanks,
>> Alex
>>
>>
>> On 3/20/15 1:38 AM, Rudy De Busscher wrote:
>>
>> Arjan,
>>
>> Thx.
>>
>> Didn't realize that the auth-methods could so easily migrated.
>>
>> Alex,
>>
>> Do we know (do you get notified, CC'ed, ...) from the other Expert
>> groups what there plans are around security? As I can read here that for
>> the new servlet spec the want to promote the role of JASPIC. This is of
>> course very important for us.
>>
>> Thx
>> Rudy
>>
>>
>> On 19 March 2015 at 23:14, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>>> Hi Rudy,
>>>
>>> On Thu, Mar 19, 2015 at 10:02 PM, Rudy De Busscher <
>>> rdebusscher_at_gmail.com> wrote:
>>>
>>>> Regarding your authentication flow, I see a few odd things. But it
>>>> better indicates the steps in the authentication process.
>>>>
>>>> But I find it a bit strange that all the auth-methods, like form,
>>>> basic, .. are under the JASPIC box.
>>>>
>>>
>>> This is what the Servlet EG is now considering (specifically Jetty was
>>> enthusiastic about this).
>>>
>>>
>>>
>>>> It is the extension point you have today, but the standard provided
>>>> mechanism in the servers rely on the realms which use Database, property
>>>> files, LDAP, etc ... (and are not using JASPIC, or I may have it wrong of
>>>> course)
>>>>
>>>
>>> There might be a small confusion here ;)
>>>
>>> The standard provided mechanisms (FORM, BASIC, etc) don't rely on
>>> "realms" (store/repository/any of the 10 other names), but *use* them to
>>> delegate the "credential check and fetching of users/roles" to. For
>>> instance, you can combine the standard auth mechanism FORM with the
>>> (non-standard) realm/store/repository/... LDAP.
>>>
>>> Now the code for FORM has to be implemented of course by a servlet
>>> container, and since a servlet container has to implement 3 other auth
>>> mechanisms (BASIC, CLIENT-CERT and DIGEST) they typically have some
>>> internal common interfaces for this and some code to switch between those 4
>>> standard auth mechanisms. These interfaces are proprietary, but they are
>>> often JASPIC like. Therefor, since many Servlet containers have already
>>> implemented JASPIC anyway and others are looking into this, those standard
>>> auth mechanisms may just as well be implemented using JASPIC.
>>>
>>> When in this example the FORM auth mechanism is implemented using the
>>> JASPIC interface, the implementation doesn't change much, and it will still
>>> delegate the "credential check and fetching of users/roles" to the LDAP
>>> realm/store/repository.
>>>
>>> I know you're familiar with JSF, so a small analogy would be the case
>>> where you have an @ManagedBean backing bean that is @Injected with a
>>> service. As you know the backing bean orchestrates the interaction with the
>>> user, while the service does not interact with the user directly and e.g.
>>> just fetches data based on input given to it by the backing bean.
>>>
>>> In this example, the backing bean would be comparable to the "auth
>>> mechanism" in security, while the service would be comparable to the
>>> "realm/store/repository/...".
>>>
>>> With regards to changing Servlet proprietary interfaces to those
>>> specified by JASPIC, an analogy would be changing the JSF specific
>>> @ManagedBean on the backing bean to CDI's @Named. The structure and
>>> function of the backing bean would largely remain the same and it will
>>> still delegate to the service as before, but it's now a CDI bean and not
>>> longer a JSF bean.
>>>
>>>
>>>> And I see that the Java EE Security Server Auth Store is marked with
>>>> the Java EE Security API label. Does this means that all existing code
>>>> today needs to be rewritten to use the new API we are going to define?
>>>>
>>>
>>> Application code not at all, as today the realm/store/repository/...
>>> is configured transparently to application code.
>>>
>>> Existing auth mechanisms (as implemented by Servlet containers) would
>>> have to support delegating the "credential check and fetching of
>>> users/roles" to the API we are going to define.
>>>
>>> This is essentially the proposal from Reza Rahman to standardize the
>>> most common realm/store/repositories. See
>>> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-9 and for a few
>>> examples of today's container specific ones see:
>>>
>>> * JBoss:
>>> http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Login_Modules.html
>>> * Resin: http://caucho.com/resin-4.0/admin/security-authenticators.xtp
>>> * GlassFish:
>>> http://docs.oracle.com/cd/E18930_01/html/821-2435/ggkuk.html
>>>
>>> Hope this makes it more clear!
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Regards
>>>> Rudy
>>>>
>>>>
>>>> On 19 March 2015 at 15:44, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>> Feel free to comment and change if I made a big mistake or something
>>>>>> really important is missing.
>>>>>
>>>>>
>>>>> I do have a few comments and questions indeed ;)
>>>>>
>>>>> First of all, there is a distinction between a "method" and
>>>>> "auth-method" in the map. Connected to "method" are all the things that are
>>>>> "auth-methods" in the Servlet spec. What is the difference here?
>>>>>
>>>>> Furthermore, connected to "auth-method" is "JASPIC" and "Plugeable".
>>>>> I don't 100% understand this. JASPIC is not a concrete auth method itself,
>>>>> but rather a set of rules (an SPI) that standardize how authentication
>>>>> modules can be plugged in a Servlet container in a portable way. The
>>>>> Servlet EG is considering to standardize on this plugeable interface for
>>>>> the implementation of the standard Servlet auth methods (Form, Basic, ...).
>>>>>
>>>>> So what would a separate "Plugeable" then mean in this context?
>>>>>
>>>>> There are currently 2 ways to plug authentication modules in a
>>>>> Servlet container; via a proprietary way (this is different for each
>>>>> Servlet container) and via JASPIC. Are we going to define a third way and
>>>>> ask the Servlet container vendors to implement that as well?
>>>>>
>>>>>
>>>>> As for "remember me", this is certainly worth a separate discussion.
>>>>> I found that it works rather well as a wrapper for an actual authentication
>>>>> method. You grouped it with "method", which is good as a concept, but in
>>>>> practice it is often explicitly called before the other methods.
>>>>>
>>>>> Remember me is therefor in my opinion a kind of pseudo method. It
>>>>> also needs its own store, where a token store seems to work best. (I did
>>>>> quite an amount of thinking how to implement this in a universal way, and
>>>>> I'm currently at this experimental implementation:
>>>>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/wrappers/RememberMeWrapper.java
>>>>> )
>>>>>
>>>>>
>>>>> Finally, I don't see any mention of JACC below the "Authorization"
>>>>> node.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 19, 2015 at 2:52 PM, Alex Kosowski <
>>>>> alex.kosowski_at_oracle.com> wrote:
>>>>>
>>>>>> Hi Rudy,
>>>>>>
>>>>>> I fixed the permissions, everyone in the group should now be allowed
>>>>>> to post to the Google Group for sharing docs.
>>>>>>
>>>>>> Please let us keep the discussions on
>>>>>> jsr375-experts_at_javaee-security-spec.java.net.
>>>>>>
>>>>>> Thanks Rudy for preparing and sharing the mindMap!
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On 3/19/15 5:47 AM, Rudy De Busscher wrote:
>>>>>>
>>>>>> Seems that I can't post to the JSR 375 Google groups ...
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Rudy De Busscher (via Google Drive) <rdebusscher_at_gmail.com>
>>>>>> Date: 19 March 2015 at 10:14
>>>>>> Subject: Security.mup
>>>>>> To: rdebusscher_at_gmail.com
>>>>>> Cc: jsr375-experts_at_googlegroups.com
>>>>>>
>>>>>>
>>>>>> Rudy De Busscher <rdebusscher_at_gmail.com> has shared the following
>>>>>> file:
>>>>>> [image: Item]
>>>>>> Security.mup
>>>>>> <https://drive.google.com/file/d/0B4QN2eZt4p5dLWF3Q0l0LTZxWWc/view?usp=sharing_eid>
>>>>>> Hi all,
>>>>>>
>>>>>> I tried to create an overview of all 'things' related to Java EE
>>>>>> Security and assembled them in a mindMap. Existing concepts and future
>>>>>> wishes (and I know it is incomplete)
>>>>>>
>>>>>> This to keep a global overview of what belongs where and what should
>>>>>> it be used for.
>>>>>>
>>>>>> Feel free to comment and change if I made a big mistake or something
>>>>>> really important is missing.
>>>>>>
>>>>>> It is created with MindMup (in case you have issues with
>>>>>> installing/using it, here is a link to an image of the mindMap
>>>>>> https://drive.google.com/file/d/0B4QN2eZt4p5dYndIT1Z6QkVoZzQ/view?usp=sharing
>>>>>> )
>>>>>>
>>>>>> Regards
>>>>>> Rudy
>>>>>> Open
>>>>>> <https://drive.google.com/file/d/0B4QN2eZt4p5dLWF3Q0l0LTZxWWc/view?usp=sharing_eid>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Google Drive: Have all your files within reach from any device. [image:
>>>>>> Logo for Google Drive] <https://drive.google.com>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>