Hi Arjan, et al,
> 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 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. 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.
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? I guess it really
depends on what changes we specify. Really just thinking out loud...
> 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 <mailto: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
>> <mailto:arjan.tijms_at_gmail.com>> wrote:
>>
>> Hi Rudy,
>>
>> On Thu, Mar 19, 2015 at 10:02 PM, Rudy De Busscher
>> <rdebusscher_at_gmail.com <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>>> <mailto:rdebusscher_at_gmail.com>>
>>> Date: 19 March 2015 at 10:14
>>> Subject: Security.mup
>>> To: rdebusscher_at_gmail.com
>>> <mailto:rdebusscher_at_gmail.com>
>>> Cc: jsr375-experts_at_googlegroups.com
>>> <mailto:jsr375-experts_at_googlegroups.com>
>>>
>>>
>>> Rudy De Busscher <mailto:rdebusscher_at_gmail.com>
>>> has shared the following file:
>>> 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. Logo for Google Drive
>>> <https://drive.google.com>
>>>
>>>
>>
>>
>>
>>
>