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