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