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>
>>>>>
>>>>>
>>>>
>>>
>>
>