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