You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by Fjodor Vershinin <fj...@vershinin.net> on 2015/02/10 19:05:56 UTC

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Hello!
I am CS student and it looks like that this task is quite interesting. I
would take it for GSOC if ASF organization will be selected. Currently I
have some time to do research in Tomcat codebase. Could you provide me some
entry points?
Thanks,
Fjodor



--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029627.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by David Jencks <da...@yahoo.com.INVALID>.

For many years Geronimo has had a modified tomcat version implementing jaspic. I offered it to tomcat when I wrote it but was declined.

thanks
david jencks

On Feb 10, 2015, at 1:05 PM, Fjodor Vershinin <fj...@vershinin.net> wrote:

> Hello!
> I am CS student and it looks like that this task is quite interesting. I
> would take it for GSOC if ASF organization will be selected. Currently I
> have some time to do research in Tomcat codebase. Could you provide me some
> entry points?
> Thanks,
> Fjodor
> 
> 
> 
> --
> View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029627.html
> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

See you guys are making good progress with the JASPIC implementation in
Tomcat.

One commit that I noticed is the following:
https://github.com/apache/tomcat/commit/3e1b4931867a12a74e9e9fe7ff86484cc65a21e6

It says: "Remove the programmatic login/logout override, as I don't see how
JASPIC can interact with it."

I haven't looked further for the exact context here, but in general JASPIC
interacts with both the corresponding methods in HttpServletRequest.

In case of login(), an exception has to be thrown when a SAM is configured.
The rationale is that a SAM can't handle just login(), as a SAM is an
authentication mechanism that may or may not delegate to an identity store.
Login() is intended to go to a server specific identity store (Tomcat calls
it realm). Since there's no standard mechanism for a SAM to delegate to
this server specific identity store, it can't handle login(), hence the
exception.

In case of logout(), next to what the server normally would do, the SAM's
cleanSubject() method has to be called.

Hope this helps.

Kind regards,
Arjan Tijms




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5043520.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-20 8:18 GMT+02:00 Fjodor Vershinin <fj...@vershinin.net>:

> Hi, I had reviewed patches left from summer. There are patches for
> supporting property configurator, SPNEGO module and some refactorings.
> You can have a look here:
> https://github.com/fjodorver/tomcat/tree/feature/spnego
> The next thing I would like to polish JASPIC implementation in order to get
> it working with Arjan's test suite.
>
> Ok, so I'll look at that.

Thanks,
Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Vershinin <fj...@vershinin.net>.

Hi, I had reviewed patches left from summer. There are patches for
supporting property configurator, SPNEGO module and some refactorings.
You can have a look here:
https://github.com/fjodorver/tomcat/tree/feature/spnego
The next thing I would like to polish JASPIC implementation in order to get
it working with Arjan's test suite.
Fjodor.

2015-10-16 22:58 GMT+03:00 Rémy Maucherat <re...@apache.org>:

> 2015-10-16 17:18 GMT+02:00 Arjan Tijms <ar...@gmail.com>:
>
> > On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
> > <ml...@n6.nabble.com> wrote:
> > > 2015-10-16 16:11 GMT+02:00 Arjan Tijms <[hidden email]>:
> > > I was not talking about this future specification, since I never had a
> > look.
> >
> > Okay, my bad. I thought it was in reply to the JSR 375 work.
> >
> > But what did you mean exactly then? Tomcat now ships with 6
> > "authenticators" if I'm not mistaken; Basic, Digest, Form, NonLogin,
> > SSL, Spnego.
> >
> > If these used the JASPIC API of Tomcat, then at least when used with
> > Tomcat these would be just as predictable when used with Tomcat as
> > they are when using the proprietary (Authenticator) API, right?
> >
> > Yes, from what I know, the goal of the GSOC project was to write
> equivalents using JASPIC, for use in Tomcat.
>
> Rémy
>



-- 
Thanks,
Fjodor

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-16 17:18 GMT+02:00 Arjan Tijms <ar...@gmail.com>:

> On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
> <ml...@n6.nabble.com> wrote:
> > 2015-10-16 16:11 GMT+02:00 Arjan Tijms <[hidden email]>:
> > I was not talking about this future specification, since I never had a
> look.
>
> Okay, my bad. I thought it was in reply to the JSR 375 work.
>
> But what did you mean exactly then? Tomcat now ships with 6
> "authenticators" if I'm not mistaken; Basic, Digest, Form, NonLogin,
> SSL, Spnego.
>
> If these used the JASPIC API of Tomcat, then at least when used with
> Tomcat these would be just as predictable when used with Tomcat as
> they are when using the proprietary (Authenticator) API, right?
>
> Yes, from what I know, the goal of the GSOC project was to write
equivalents using JASPIC, for use in Tomcat.

Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
<ml...@n6.nabble.com> wrote:
> 2015-10-16 16:11 GMT+02:00 Arjan Tijms <[hidden email]>:
> I was not talking about this future specification, since I never had a look.

Okay, my bad. I thought it was in reply to the JSR 375 work.

But what did you mean exactly then? Tomcat now ships with 6
"authenticators" if I'm not mistaken; Basic, Digest, Form, NonLogin,
SSL, Spnego.

If these used the JASPIC API of Tomcat, then at least when used with
Tomcat these would be just as predictable when used with Tomcat as
they are when using the proprietary (Authenticator) API, right?


> So I plan to review the three auth modules that have been contributed,
> that's a start.

Good start indeed ;)

Kind regards,
Arjan Tijms


>
> Rémy
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040857.html
> To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here.
> NAML




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040860.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-16 16:11 GMT+02:00 Arjan Tijms <ar...@gmail.com>:

> Hi,
>
> On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat]
> <ml...@n6.nabble.com> wrote:
> > I still think it is far preferable at the moment to implement 4 or 5
> > proprietary auth "modules"
>
> Well, the higher level functionality does not necessarily mean that
> JSR 375 is going to provide standard authentication modules that build
> on top of JASPIC (although this was mentioned at some point). It's for
> now more like introducing convenience APIs so users can more easily
> create their own custom modules.
>

I was not talking about this future specification, since I never had a look.

So I plan to review the three auth modules that have been contributed,
that's a start.

Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat]
<ml...@n6.nabble.com> wrote:
> I still think it is far preferable at the moment to implement 4 or 5
> proprietary auth "modules"

Well, the higher level functionality does not necessarily mean that
JSR 375 is going to provide standard authentication modules that build
on top of JASPIC (although this was mentioned at some point). It's for
now more like introducing convenience APIs so users can more easily
create their own custom modules.

> that will behave predictably than try to use
> this standard API that is far more complex and has behavior differences on
> each server.

Historically very little code has indeed been 100% portable between
implementations of various APIs. Be it JPA, CDI, or even Servlet.

That said, proprietary implementations of FORM may not all behave in
exactly the same way either. They should, but I remember having seen
small differences in the past where it concerns forwards, includes and
redirects.

So while I generally agree that there can be behavioral differences
between each server, I'm not really sure if using the standard API vs
proprietary API will make a huge difference there.

Also, JASPIC is not a terribly complex API. Tedious for some things
maybe, and low level and abstract, but it's rather small really and
not overly complex (IMHO).

> Of course it would be better if this was not the case.

Of course, so another ongoing business is testing the implementations
of all vendors and reporting behavioral differences and spec
violations to them. I've added many of those to a series of tests
here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic

Some of those are likely to be fed back into the official TCK (which
for EE 7 is really small, unfortunately).

Kind regards,
Arjan Tijms

--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040856.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-16 13:25 GMT+02:00 Arjan Tijms <ar...@gmail.com>:

> Hi,
>
> Those are indeed the main reasons for JASPIC. JASPIC authentication
> modules should be fully equivalent to any of the build-in
> authentication mechanisms like FORM, BASIC, etc in terms of what they
> can do and how they are treated by the container.
>
> This specifically means they fully integrate with any of the existing
> security mechanisms, such as constraints in web.xml.
>
> An other advantage of JASPIC is that the same authentication module
> can be either installed at the container, shipped with the
> application, or deployed separately (via its own war).
>
> Furthermore, the Security EG (JSR 375) is looking at building higher
> level functionality that uses the JASPIC APIs as a base, so this may
> possibly increase the demand for JASPIC in the future.
>
> I still think it is far preferable at the moment to implement 4 or 5
proprietary auth "modules" that will behave predictably than try to use
this standard API that is far more complex and has behavior differences on
each server. Of course it would be better if this was not the case.

Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Fri, Oct 16, 2015 at 12:56 PM, Jess Holle [via Tomcat]
<ml...@n6.nabble.com> wrote:
> My understanding with JASPIC is that one should be able to add
> authentication mechanisms that (1) use the same code across any
> container that supports JASPIC [as Mark notes] and (2) still use
> standard security constraints in one's web.xml to configure
> authentication constraints.

Those are indeed the main reasons for JASPIC. JASPIC authentication
modules should be fully equivalent to any of the build-in
authentication mechanisms like FORM, BASIC, etc in terms of what they
can do and how they are treated by the container.

This specifically means they fully integrate with any of the existing
security mechanisms, such as constraints in web.xml.

An other advantage of JASPIC is that the same authentication module
can be either installed at the container, shipped with the
application, or deployed separately (via its own war).

Furthermore, the Security EG (JSR 375) is looking at building higher
level functionality that uses the JASPIC APIs as a base, so this may
possibly increase the demand for JASPIC in the future.

Kind regards,
Arjan Tijms

>
> --
> Jess Holle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040848.html
> To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here.
> NAML

--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040852.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-16 12:51 GMT+02:00 Mark Thomas <ma...@apache.org>:

> The main benefit for me is that once Tomcat implements JASPIC, there are
> a handful of 3rd party modules that users will then be able to use just
> by adding the lib to Tomcat. It also provides a standard API for users
> to work against if they want to develop their own custom modules. Those
> modules would then be usable with any container that implements JASPIC.
>
> Ok, noted, I think I understand the requirements a bit better now since
otherwise I didn't quite see the point. Fjodor: did you explore/test this
capability ?

Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Jess Holle <je...@ptc.com>.

On 10/16/2015 5:51 AM, Mark Thomas wrote:
> On 16/10/2015 11:44, Rémy Maucherat wrote:
>> What's not clear to me at this point is if jaspic should replace the
>> current "classic" auth methods. For example, the supposed benefit of jaspic
>> is that it makes container auth not proprietary, but looking at the code
>> that is there it sounds still quite proprietary in practice and almost
>> impossible to use from webapps. So what's the point exactly ?
> The main benefit for me is that once Tomcat implements JASPIC, there are
> a handful of 3rd party modules that users will then be able to use just
> by adding the lib to Tomcat. It also provides a standard API for users
> to work against if they want to develop their own custom modules. Those
> modules would then be usable with any container that implements JASPIC.

Today if one wants a portable but custom authentication mechanism, one 
has to forgo/remove security constraints from one's web.xml and 
implement the mechanism as a servlet request filter -- with its own 
security constraint configuration mechanisms.

My understanding with JASPIC is that one should be able to add 
authentication mechanisms that (1) use the same code across any 
container that supports JASPIC [as Mark notes] and (2) still use 
standard security constraints in one's web.xml to configure 
authentication constraints.

--
Jess Holle

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 16/10/2015 11:44, Rémy Maucherat wrote:

<snip/>

> What's not clear to me at this point is if jaspic should replace the
> current "classic" auth methods. For example, the supposed benefit of jaspic
> is that it makes container auth not proprietary, but looking at the code
> that is there it sounds still quite proprietary in practice and almost
> impossible to use from webapps. So what's the point exactly ?

The main benefit for me is that once Tomcat implements JASPIC, there are
a handful of 3rd party modules that users will then be able to use just
by adding the lib to Tomcat. It also provides a standard API for users
to work against if they want to develop their own custom modules. Those
modules would then be usable with any container that implements JASPIC.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Rémy Maucherat <re...@apache.org>.

2015-10-15 3:03 GMT+02:00 Fjodor Versinin <fj...@vershinin.net>:

> Hi!
> Actually, I would like to continue to work on this, but not in GSOC scope
> anymore, because that expirience was too stressful for me.
> What about current JASPIC implementation, it is almost ready, so I think
> it would be better to keep already wroten code than rewriting it from a
> scratch. What about security, I'm not sure, but this code has been accepted
> during the summer time, it has not be changed since then. Security must be
> on the same level,  I hope so. However,  some places of old auth valves
> should be rewritten in more readable way.
>
> I'll review the jaspic work as much as possible. Feel free to continue
sending patches.

OTOH, starting with reviewing the basics (BASIC actually), I now understand
why Mark isn't very comfortable with the code:
In BasicAuthModule, I have:
        try {
            PasswordValidationCallback passwordCallback = new
PasswordValidationCallback(
                    clientSubject, username, password);
            handler.handle(new Callback[] { passwordCallback });

            if (!passwordCallback.getResult()) {
 >>>>>               sendUnauthorizedError(response, realmName);
            }
            handlePrincipalCallbacks(clientSubject,
getPrincipal(passwordCallback));
            return AuthStatus.SUCCESS;

        } catch (Exception e) {
            throw new AuthException(e.getMessage());
        }

Ok, so that actually lets in everyone unless there's an exception :) It
should be "return sendUnauthorizedError" I think.

What's not clear to me at this point is if jaspic should replace the
current "classic" auth methods. For example, the supposed benefit of jaspic
is that it makes container auth not proprietary, but looking at the code
that is there it sounds still quite proprietary in practice and almost
impossible to use from webapps. So what's the point exactly ?

Rémy

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 15/10/2015 02:03, Fjodor Versinin wrote:
> Hi! Actually, I would like to continue to work on this, but not in
> GSOC scope anymore, because that expirience was too stressful for
> me. What about current JASPIC implementation, it is almost ready, so
> I think it would be better to keep already wroten code than rewriting
> it from a scratch. What about security, I'm not sure, but this code
> has been accepted during the summer time, it has not be changed since
> then. Security must be on the same level,  I hope so.

It isn't really a case of re-writing from scratch but of validating that
the new code is secure. The nature of the code is that a very small
change could introduce a very large security hole.

Because this code is security related it requires a degree of trust in
the source. That trust was eroded when you disappeared without any
communication immediately you passed the mid-term evaluation.

There are two ways the code could be validated. The first is to examine
line, by line, every commit based on your contributed patches. That
would be extremely time consuming. The faster way is to use your patches
as a guide to independently re-create the patches.

Given that the changes need to be ported to the
org.apache.catalina.authenticator package from their current
sub-package, it looks like the best way forward is to combine that
process with validating the code in the jaspic sub-package. That way you
can continue to provide patches/pull-requests against the jaspic
sub-package and the review / porting work can progress independently.
When both are complete we can simply remove the jaspic sub-package.

> However,  some
> places of old auth valves should be rewritten in more readable way.

I'd recommend keeping re-factoring and JASPIC implementation separate.
By all means progress them in parallel but don't mix the purpose of the
patches.

Mark

> 
> Fjodor
> 
> ---- Mark Thomas wrote ----
> 
>> On 14/10/2015 13:00, Arjan Tijms wrote:
>>> Hi there,
>>> 
>>> Haven't seen updates for some time here. Wonder what the current 
>>> status is and what exactly happened in the last months. Last
>>> commits in the Tomcat repo are from 3 months ago.
>> 
>> The GSoC student took the money and ran at the mid-term evaluation.
>> I should have gone with my first instinct which was to fail them at
>> the mid-term due to lack of effort.
>> 
>> Getting back to this is on my TODO list for Tomcat 9. I plan to
>> remove the GSoC work and start again from scratch. While that might
>> seem excessive I simply do not trust the refactoring that Fjodor
>> completed is secure. It will be quicker to re-do the work myself
>> than it will be to check the refactoring line by line.
>> 
>> Mark
>> 
>> 
>>> 
>>> Kind regards, Arjan Tijms

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Versinin <fj...@vershinin.net>.

Hi!
Actually, I would like to continue to work on this, but not in GSOC scope anymore, because that expirience was too stressful for me.
What about current JASPIC implementation, it is almost ready, so I think it would be better to keep already wroten code than rewriting it from a scratch. What about security, I'm not sure, but this code has been accepted during the summer time, it has not be changed since then. Security must be on the same level,  I hope so. However,  some places of old auth valves should be rewritten in more readable way.

Fjodor

---- Mark Thomas wrote ----

>On 14/10/2015 13:00, Arjan Tijms wrote:
>> Hi there,
>> 
>> Haven't seen updates for some time here. Wonder what the current
>> status is and what exactly happened in the last months. Last commits
>> in the Tomcat repo are from 3 months ago.
>
>The GSoC student took the money and ran at the mid-term evaluation. I
>should have gone with my first instinct which was to fail them at the
>mid-term due to lack of effort.
>
>Getting back to this is on my TODO list for Tomcat 9. I plan to remove
>the GSoC work and start again from scratch. While that might seem
>excessive I simply do not trust the refactoring that Fjodor completed is
>secure. It will be quicker to re-do the work myself than it will be to
>check the refactoring line by line.
>
>Mark
>
>
>> 
>> Kind regards,
>> Arjan Tijms
>> 
>> 
>> 
>> On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat]
>> <ml...@n6.nabble.com> wrote:
>>> On 10/06/2015 16:43, Arjan Tijms wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
>>>> [hidden email]> wrote:
>>>>
>>>>> I don't really understand what the requirement is here. Can you expand /
>>>>> point me to the part of the spec?
>>>>>
>>>>
>>>> It's simply that from within a SAM you can forward/include to a Servlet
>>>> using a dispatcher, such that the output of that Servlet is inserted in
>>>> the
>>>> response.
>>>
>>> Thanks for the clarification. You can do that easily from a Valve in a
>>> couple of lines of code. No need for extra internal plumbing that I can see.
>>>
>>> Mark
>>>
>>>>
>>>> It's in section 3.8.3.4 of the JASPIC spec:
>>>>
>>>>
>>>> "3.8.3.4
>>>> Forwards and Includes by Server Authentication Modules
>>>>
>>>> The message processing runtime must support the acquisition and use of
>>>> RequestDispatcher objects by authentication modules within their
>>>> processing
>>>> of validateRequest.
>>>>
>>>> Under the constraints defined by RequestDispatcher, authentication modules
>>>> must be able to forward and include using the request and response objects
>>>> passed in MessageInfo. In particular, an authentication module must be
>>>> able
>>>> to acquire a RequestDispatcher from the request obtained from MessageInfo,
>>>> and uses it to forward the request (and response) to a login form.
>>>> Authentication modules should catch and rethrow as an AuthException any
>>>> exception thrown by these methods."
>>>>
>>>>
>>>> A test/example showing this in practice is the following:
>>>>
>>>>
>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
>>>>
>>>> Specifically, this code shows both an include and a forward done by a SAM:
>>>>
>>>>   public AuthStatus validateRequest(MessageInfo messageInfo, Subject
>>>> clientSubject, Subject serviceSubject) throws AuthException {
>>>>         try {
>>>>             HttpServletRequest request = (HttpServletRequest)
>>>> messageInfo.getRequestMessage();
>>>>             HttpServletResponse response = (HttpServletResponse)
>>>> messageInfo.getResponseMessage();
>>>>
>>>>             if ("include".equals(request.getParameter("dispatch"))) {
>>>>                 request.getRequestDispatcher("/includedServlet")
>>>>                        .include(request, response);
>>>>
>>>>                 // "Do nothing", required protocol when returning SUCCESS
>>>>                 handler.handle(new Callback[] { new
>>>> CallerPrincipalCallback(clientSubject, (Principal) null) });
>>>>
>>>>                 // When using includes, the response stays open and the
>>>> main
>>>>                 // resource can also write to the response
>>>>                 return SUCCESS;
>>>>
>>>>             } else {
>>>>                 request.getRequestDispatcher("/forwardedServlet")
>>>>                        .forward(request, response);
>>>>
>>>>                 // MUST NOT invoke the resource, so CAN NOT return SUCCESS
>>>> here.
>>>>                 return SEND_CONTINUE;
>>>>             }
>>>>
>>>>         } catch (IOException | ServletException |
>>>> UnsupportedCallbackException e) {
>>>>             throw (AuthException) new AuthException().initCause(e);
>>>>         }
>>>>     }
>>>>
>>>>
>>>> Sounds good. Thanks for the tip.
>>>>>
>>>>
>>>> You're welcome ;)
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
>>>>> For additional commands, e-mail: [hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>  If you reply to this email, your message will be added to the discussion
>>>>> below:
>>>>>
>>>>>
>>>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>>>>  To unsubscribe from Consider support for the Servlet profile of JSR 196
>>>>> (JASPIC) in Tomcat 7.0.x, click here
>>>>> <
>>>>> .
>>>>> NAML
>>>>>
>>>>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
>>>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>> ________________________________
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035913.html
>>> To unsubscribe from Consider support for the Servlet profile of JSR 196
>>> (JASPIC) in Tomcat 7.0.x, click here.
>>> NAML
>> 
>> 
>> 
>> 
>> --
>> View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040745.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
>

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 14/10/2015 13:00, Arjan Tijms wrote:
> Hi there,
> 
> Haven't seen updates for some time here. Wonder what the current
> status is and what exactly happened in the last months. Last commits
> in the Tomcat repo are from 3 months ago.

The GSoC student took the money and ran at the mid-term evaluation. I
should have gone with my first instinct which was to fail them at the
mid-term due to lack of effort.

Getting back to this is on my TODO list for Tomcat 9. I plan to remove
the GSoC work and start again from scratch. While that might seem
excessive I simply do not trust the refactoring that Fjodor completed is
secure. It will be quicker to re-do the work myself than it will be to
check the refactoring line by line.

Mark


> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
> On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat]
> <ml...@n6.nabble.com> wrote:
>> On 10/06/2015 16:43, Arjan Tijms wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
>>> [hidden email]> wrote:
>>>
>>>> I don't really understand what the requirement is here. Can you expand /
>>>> point me to the part of the spec?
>>>>
>>>
>>> It's simply that from within a SAM you can forward/include to a Servlet
>>> using a dispatcher, such that the output of that Servlet is inserted in
>>> the
>>> response.
>>
>> Thanks for the clarification. You can do that easily from a Valve in a
>> couple of lines of code. No need for extra internal plumbing that I can see.
>>
>> Mark
>>
>>>
>>> It's in section 3.8.3.4 of the JASPIC spec:
>>>
>>>
>>> "3.8.3.4
>>> Forwards and Includes by Server Authentication Modules
>>>
>>> The message processing runtime must support the acquisition and use of
>>> RequestDispatcher objects by authentication modules within their
>>> processing
>>> of validateRequest.
>>>
>>> Under the constraints defined by RequestDispatcher, authentication modules
>>> must be able to forward and include using the request and response objects
>>> passed in MessageInfo. In particular, an authentication module must be
>>> able
>>> to acquire a RequestDispatcher from the request obtained from MessageInfo,
>>> and uses it to forward the request (and response) to a login form.
>>> Authentication modules should catch and rethrow as an AuthException any
>>> exception thrown by these methods."
>>>
>>>
>>> A test/example showing this in practice is the following:
>>>
>>>
>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
>>>
>>> Specifically, this code shows both an include and a forward done by a SAM:
>>>
>>>   public AuthStatus validateRequest(MessageInfo messageInfo, Subject
>>> clientSubject, Subject serviceSubject) throws AuthException {
>>>         try {
>>>             HttpServletRequest request = (HttpServletRequest)
>>> messageInfo.getRequestMessage();
>>>             HttpServletResponse response = (HttpServletResponse)
>>> messageInfo.getResponseMessage();
>>>
>>>             if ("include".equals(request.getParameter("dispatch"))) {
>>>                 request.getRequestDispatcher("/includedServlet")
>>>                        .include(request, response);
>>>
>>>                 // "Do nothing", required protocol when returning SUCCESS
>>>                 handler.handle(new Callback[] { new
>>> CallerPrincipalCallback(clientSubject, (Principal) null) });
>>>
>>>                 // When using includes, the response stays open and the
>>> main
>>>                 // resource can also write to the response
>>>                 return SUCCESS;
>>>
>>>             } else {
>>>                 request.getRequestDispatcher("/forwardedServlet")
>>>                        .forward(request, response);
>>>
>>>                 // MUST NOT invoke the resource, so CAN NOT return SUCCESS
>>> here.
>>>                 return SEND_CONTINUE;
>>>             }
>>>
>>>         } catch (IOException | ServletException |
>>> UnsupportedCallbackException e) {
>>>             throw (AuthException) new AuthException().initCause(e);
>>>         }
>>>     }
>>>
>>>
>>> Sounds good. Thanks for the tip.
>>>>
>>>
>>> You're welcome ;)
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>>
>>>> mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
>>>> For additional commands, e-mail: [hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>  If you reply to this email, your message will be added to the discussion
>>>> below:
>>>>
>>>>
>>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>>>  To unsubscribe from Consider support for the Servlet profile of JSR 196
>>>> (JASPIC) in Tomcat 7.0.x, click here
>>>> <
>>>> .
>>>> NAML
>>>>
>>>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
>>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035913.html
>> To unsubscribe from Consider support for the Servlet profile of JSR 196
>> (JASPIC) in Tomcat 7.0.x, click here.
>> NAML
> 
> 
> 
> 
> --
> View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040745.html
> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

RE: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by gradstud <gr...@ucalgary.ca>.

Is there any way you can use another email then this one to have your conversations? Thank you!

-----Original Message-----
From: Arjan Tijms [mailto:arjan.tijms@gmail.com] 
Sent: Wednesday, October 14, 2015 6:01 AM
To: dev@tomcat.apache.org
Subject: Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Hi there,

Haven't seen updates for some time here. Wonder what the current status is and what exactly happened in the last months. Last commits in the Tomcat repo are from 3 months ago.

Kind regards,
Arjan Tijms



On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat] <ml...@n6.nabble.com> wrote:
> On 10/06/2015 16:43, Arjan Tijms wrote:
>
>> Hi,
>>
>> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] < [hidden email]> 
>> wrote:
>>
>>> I don't really understand what the requirement is here. Can you 
>>> expand / point me to the part of the spec?
>>>
>>
>> It's simply that from within a SAM you can forward/include to a 
>> Servlet using a dispatcher, such that the output of that Servlet is 
>> inserted in the response.
>
> Thanks for the clarification. You can do that easily from a Valve in a 
> couple of lines of code. No need for extra internal plumbing that I can see.
>
> Mark
>
>>
>> It's in section 3.8.3.4 of the JASPIC spec:
>>
>>
>> "3.8.3.4
>> Forwards and Includes by Server Authentication Modules
>>
>> The message processing runtime must support the acquisition and use 
>> of RequestDispatcher objects by authentication modules within their 
>> processing of validateRequest.
>>
>> Under the constraints defined by RequestDispatcher, authentication 
>> modules must be able to forward and include using the request and 
>> response objects passed in MessageInfo. In particular, an 
>> authentication module must be able to acquire a RequestDispatcher 
>> from the request obtained from MessageInfo, and uses it to forward 
>> the request (and response) to a login form.
>> Authentication modules should catch and rethrow as an AuthException 
>> any exception thrown by these methods."
>>
>>
>> A test/example showing this in practice is the following:
>>
>>
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/
>> dispatching
>>
>> Specifically, this code shows both an include and a forward done by a SAM:
>>
>>   public AuthStatus validateRequest(MessageInfo messageInfo, Subject 
>> clientSubject, Subject serviceSubject) throws AuthException {
>>         try {
>>             HttpServletRequest request = (HttpServletRequest) 
>> messageInfo.getRequestMessage();
>>             HttpServletResponse response = (HttpServletResponse) 
>> messageInfo.getResponseMessage();
>>
>>             if ("include".equals(request.getParameter("dispatch"))) {
>>                 request.getRequestDispatcher("/includedServlet")
>>                        .include(request, response);
>>
>>                 // "Do nothing", required protocol when returning SUCCESS
>>                 handler.handle(new Callback[] { new 
>> CallerPrincipalCallback(clientSubject, (Principal) null) });
>>
>>                 // When using includes, the response stays open and 
>> the main
>>                 // resource can also write to the response
>>                 return SUCCESS;
>>
>>             } else {
>>                 request.getRequestDispatcher("/forwardedServlet")
>>                        .forward(request, response);
>>
>>                 // MUST NOT invoke the resource, so CAN NOT return 
>> SUCCESS here.
>>                 return SEND_CONTINUE;
>>             }
>>
>>         } catch (IOException | ServletException | 
>> UnsupportedCallbackException e) {
>>             throw (AuthException) new AuthException().initCause(e);
>>         }
>>     }
>>
>>
>> Sounds good. Thanks for the tip.
>>>
>>
>> You're welcome ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> mark
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: [hidden email] 
>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
>>> For additional commands, e-mail: [hidden email] 
>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>>>
>>>
>>>
>>> ------------------------------
>>>  If you reply to this email, your message will be added to the 
>>> discussion
>>> below:
>>>
>>>
>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-prof
>>> ile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>>  To unsubscribe from Consider support for the Servlet profile of JSR 
>>> 196
>>> (JASPIC) in Tomcat 7.0.x, click here < .
>>> NAML
>>>
>>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro
>>> _viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
>>> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble
>>> .view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21na
>>> bble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_
>>> email%21nabble%3Aemail.naml>
>>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profi
>> le-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional commands, 
> e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the 
> discussion
> below:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profil
> e-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035913.html
> To unsubscribe from Consider support for the Servlet profile of JSR 
> 196
> (JASPIC) in Tomcat 7.0.x, click here.
> NAML




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040745.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi there,

Haven't seen updates for some time here. Wonder what the current
status is and what exactly happened in the last months. Last commits
in the Tomcat repo are from 3 months ago.

Kind regards,
Arjan Tijms



On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat]
<ml...@n6.nabble.com> wrote:
> On 10/06/2015 16:43, Arjan Tijms wrote:
>
>> Hi,
>>
>> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
>> [hidden email]> wrote:
>>
>>> I don't really understand what the requirement is here. Can you expand /
>>> point me to the part of the spec?
>>>
>>
>> It's simply that from within a SAM you can forward/include to a Servlet
>> using a dispatcher, such that the output of that Servlet is inserted in
>> the
>> response.
>
> Thanks for the clarification. You can do that easily from a Valve in a
> couple of lines of code. No need for extra internal plumbing that I can see.
>
> Mark
>
>>
>> It's in section 3.8.3.4 of the JASPIC spec:
>>
>>
>> "3.8.3.4
>> Forwards and Includes by Server Authentication Modules
>>
>> The message processing runtime must support the acquisition and use of
>> RequestDispatcher objects by authentication modules within their
>> processing
>> of validateRequest.
>>
>> Under the constraints defined by RequestDispatcher, authentication modules
>> must be able to forward and include using the request and response objects
>> passed in MessageInfo. In particular, an authentication module must be
>> able
>> to acquire a RequestDispatcher from the request obtained from MessageInfo,
>> and uses it to forward the request (and response) to a login form.
>> Authentication modules should catch and rethrow as an AuthException any
>> exception thrown by these methods."
>>
>>
>> A test/example showing this in practice is the following:
>>
>>
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
>>
>> Specifically, this code shows both an include and a forward done by a SAM:
>>
>>   public AuthStatus validateRequest(MessageInfo messageInfo, Subject
>> clientSubject, Subject serviceSubject) throws AuthException {
>>         try {
>>             HttpServletRequest request = (HttpServletRequest)
>> messageInfo.getRequestMessage();
>>             HttpServletResponse response = (HttpServletResponse)
>> messageInfo.getResponseMessage();
>>
>>             if ("include".equals(request.getParameter("dispatch"))) {
>>                 request.getRequestDispatcher("/includedServlet")
>>                        .include(request, response);
>>
>>                 // "Do nothing", required protocol when returning SUCCESS
>>                 handler.handle(new Callback[] { new
>> CallerPrincipalCallback(clientSubject, (Principal) null) });
>>
>>                 // When using includes, the response stays open and the
>> main
>>                 // resource can also write to the response
>>                 return SUCCESS;
>>
>>             } else {
>>                 request.getRequestDispatcher("/forwardedServlet")
>>                        .forward(request, response);
>>
>>                 // MUST NOT invoke the resource, so CAN NOT return SUCCESS
>> here.
>>                 return SEND_CONTINUE;
>>             }
>>
>>         } catch (IOException | ServletException |
>> UnsupportedCallbackException e) {
>>             throw (AuthException) new AuthException().initCause(e);
>>         }
>>     }
>>
>>
>> Sounds good. Thanks for the tip.
>>>
>>
>> You're welcome ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
>>> For additional commands, e-mail: [hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>>>
>>>
>>>
>>> ------------------------------
>>>  If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>>
>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>>  To unsubscribe from Consider support for the Servlet profile of JSR 196
>>> (JASPIC) in Tomcat 7.0.x, click here
>>> <
>>> .
>>> NAML
>>>
>>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035913.html
> To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here.
> NAML




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040745.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 10/06/2015 16:43, Arjan Tijms wrote:
> Hi,
> 
> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
> ml-node+s10n5035887h73@n6.nabble.com> wrote:
> 
>> I don't really understand what the requirement is here. Can you expand /
>> point me to the part of the spec?
>>
> 
> It's simply that from within a SAM you can forward/include to a Servlet
> using a dispatcher, such that the output of that Servlet is inserted in the
> response.

Thanks for the clarification. You can do that easily from a Valve in a
couple of lines of code. No need for extra internal plumbing that I can see.

Mark

> 
> It's in section 3.8.3.4 of the JASPIC spec:
> 
> 
> "3.8.3.4
> Forwards and Includes by Server Authentication Modules
> 
> The message processing runtime must support the acquisition and use of
> RequestDispatcher objects by authentication modules within their processing
> of validateRequest.
> 
> Under the constraints defined by RequestDispatcher, authentication modules
> must be able to forward and include using the request and response objects
> passed in MessageInfo. In particular, an authentication module must be able
> to acquire a RequestDispatcher from the request obtained from MessageInfo,
> and uses it to forward the request (and response) to a login form.
> Authentication modules should catch and rethrow as an AuthException any
> exception thrown by these methods."
> 
> 
> A test/example showing this in practice is the following:
> 
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
> 
> Specifically, this code shows both an include and a forward done by a SAM:
> 
>   public AuthStatus validateRequest(MessageInfo messageInfo, Subject
> clientSubject, Subject serviceSubject) throws AuthException {
>         try {
>             HttpServletRequest request = (HttpServletRequest)
> messageInfo.getRequestMessage();
>             HttpServletResponse response = (HttpServletResponse)
> messageInfo.getResponseMessage();
> 
>             if ("include".equals(request.getParameter("dispatch"))) {
>                 request.getRequestDispatcher("/includedServlet")
>                        .include(request, response);
> 
>                 // "Do nothing", required protocol when returning SUCCESS
>                 handler.handle(new Callback[] { new
> CallerPrincipalCallback(clientSubject, (Principal) null) });
> 
>                 // When using includes, the response stays open and the main
>                 // resource can also write to the response
>                 return SUCCESS;
> 
>             } else {
>                 request.getRequestDispatcher("/forwardedServlet")
>                        .forward(request, response);
> 
>                 // MUST NOT invoke the resource, so CAN NOT return SUCCESS
> here.
>                 return SEND_CONTINUE;
>             }
> 
>         } catch (IOException | ServletException |
> UnsupportedCallbackException e) {
>             throw (AuthException) new AuthException().initCause(e);
>         }
>     }
> 
> 
> Sounds good. Thanks for the tip.
>>
> 
> You're welcome ;)
> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
> 
>>
>> Cheers,
>>
>> mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
>> For additional commands, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>>
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>  To unsubscribe from Consider support for the Servlet profile of JSR 196
>> (JASPIC) in Tomcat 7.0.x, click here
>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
>> .
>> NAML
>> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
> 
> 
> 
> 
> --
> View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
ml-node+s10n5035887h73@n6.nabble.com> wrote:

> I don't really understand what the requirement is here. Can you expand /
> point me to the part of the spec?
>

It's simply that from within a SAM you can forward/include to a Servlet
using a dispatcher, such that the output of that Servlet is inserted in the
response.

It's in section 3.8.3.4 of the JASPIC spec:


"3.8.3.4
Forwards and Includes by Server Authentication Modules

The message processing runtime must support the acquisition and use of
RequestDispatcher objects by authentication modules within their processing
of validateRequest.

Under the constraints defined by RequestDispatcher, authentication modules
must be able to forward and include using the request and response objects
passed in MessageInfo. In particular, an authentication module must be able
to acquire a RequestDispatcher from the request obtained from MessageInfo,
and uses it to forward the request (and response) to a login form.
Authentication modules should catch and rethrow as an AuthException any
exception thrown by these methods."


A test/example showing this in practice is the following:

https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching

Specifically, this code shows both an include and a forward done by a SAM:

  public AuthStatus validateRequest(MessageInfo messageInfo, Subject
clientSubject, Subject serviceSubject) throws AuthException {
        try {
            HttpServletRequest request = (HttpServletRequest)
messageInfo.getRequestMessage();
            HttpServletResponse response = (HttpServletResponse)
messageInfo.getResponseMessage();

            if ("include".equals(request.getParameter("dispatch"))) {
                request.getRequestDispatcher("/includedServlet")
                       .include(request, response);

                // "Do nothing", required protocol when returning SUCCESS
                handler.handle(new Callback[] { new
CallerPrincipalCallback(clientSubject, (Principal) null) });

                // When using includes, the response stays open and the main
                // resource can also write to the response
                return SUCCESS;

            } else {
                request.getRequestDispatcher("/forwardedServlet")
                       .forward(request, response);

                // MUST NOT invoke the resource, so CAN NOT return SUCCESS
here.
                return SEND_CONTINUE;
            }

        } catch (IOException | ServletException |
UnsupportedCallbackException e) {
            throw (AuthException) new AuthException().initCause(e);
        }
    }


Sounds good. Thanks for the tip.
>

You're welcome ;)

Kind regards,
Arjan Tijms




>
> Cheers,
>
> mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035887&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035887&i=1>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 10/06/2015 14:04, Arjan Tijms wrote:

>> We are implementing JASPIC 1.1, and there will be quite a
>> lot changes anyway.
> 
> 
> JASPIC 1.1 itself was not a huge change over JASPIC 1.0, but it did put
> some extra requirements in place like the ability to forward and include
> resources using the HttpServletRequest and HttpServletResponse that's made
> available to a SAM.
> 
> If a Tomcat valve can already do forwards/includes correctly, then this is
> trivial to support (no extra code needed). However, IFF Tomcat would not
> support those, then some extra coding inside Tomcat's internals *may* be
> needed (but Mark would know more about how to forward then).

I don't really understand what the requirement is here. Can you expand /
point me to the part of the spec?

> Not necessarily. JASPIC is first and foremost configured using a
> programmatic API from within the application. See
> http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

Interesting.

> Optionally (but highly recommended!) a JASPIC authentication module can be
> registered at the container level using a vendor specific mechanism. If I'm
> not mistaken Mark made some remarks about this earlier. Tomcat already has
> some dedicated configuration files for this.

My expectation is that all of Tomcat's existing authentication
mechanisms would be made available at the container level (BASIC,
DIGEST, FORM, CLIENT-CERT, SPNEGO).

It should be a small step from there to replacing Tomcat's current
authenticators with the appropriate JASPIC config.

> My take is that for step 1 it's best to focus on the programmatic
> installation of an authentication module (and wrapper artifacts) first, and
> make sure the most simple authentication case works (which means just
> passing the username/roles to the container and doing nothing else).
> 
> Then look at the container side registration later.

Sounds good. Thanks for the tip.

Cheers,

mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Wed, Jun 10, 2015 at 2:31 PM, Fjodor Vershinin [via Tomcat] <
ml-node+s10n5035882h18@n6.nabble.com> wrote:

> Hi, guys!
> This week goal is to replace current valve based authentication with
> JASPIC
> based mechanism. It is what I am currently working on.
>

Nice ;)



> From my research Geronimo's implementation is also based on tomcat's
> valves, and it's pretty straightforward how to integrate SecurityValve
> into
> Tomcat's codebase. However, I am not sure, is that correct way?


I'm pretty sure this should be the way forward, or at the very least the
place where to start.


> Do you have
> better ideas? And what about code backward compatibility for Geronimo,
> should code ported back, or new Geronimo release can use our
> implementation?


I can't speak for the Apache organization of course, but as an external
observer I wouldn't hold my breath for a new Geronimo release.

See David Blevins comments here:
http://arjan-tijms.omnifaces.org/2014/05/implementation-components-used-by.html


> We are implementing JASPIC 1.1, and there will be quite a
> lot changes anyway.


JASPIC 1.1 itself was not a huge change over JASPIC 1.0, but it did put
some extra requirements in place like the ability to forward and include
resources using the HttpServletRequest and HttpServletResponse that's made
available to a SAM.

If a Tomcat valve can already do forwards/includes correctly, then this is
trivial to support (no extra code needed). However, IFF Tomcat would not
support those, then some extra coding inside Tomcat's internals *may* be
needed (but Mark would know more about how to forward then).


> Also, Geronimo uses OSGi framework in their code, which
> must be dropped off, because Tomcat is not OSGi based.
> What about JASPIC configuration, I am curious, where we want to hold
> configuration files. Different vendors use special xml files, for example
> geronimo-web.xml, for configuring realms and other security stuff. Do we
> need something like tomcat-web.xml?


Not necessarily. JASPIC is first and foremost configured using a
programmatic API from within the application. See
http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

When an application performs this programmatic configuration (typically
from a @WebListener/ServletContextListener), it overrides whatever
auth-method is configured in web.xml, e.g. FORM, BASIC, etc. It's more or
less a best practice not to put any auth-method in web.xml if the
application configures JASPIC.

When a JASPIC authentication module is configured programmatically via the
standard JASPIC API, there is not really a mechanism available to delegate
user/role retrieval to an identity store (Tomcat calls this realm). The
JASPIC module is in full control then and ought to handle this itself using
whatever internal mechanism it sees fit.

Optionally (but highly recommended!) a JASPIC authentication module can be
registered at the container level using a vendor specific mechanism. If I'm
not mistaken Mark made some remarks about this earlier. Tomcat already has
some dedicated configuration files for this.

My take is that for step 1 it's best to focus on the programmatic
installation of an authentication module (and wrapper artifacts) first, and
make sure the most simple authentication case works (which means just
passing the username/roles to the container and doing nothing else).

Then look at the container side registration later.


> And what about JACC support? Geronimo uses JACC for authorization config,
> what about Tomcat?
>

JACC is an entirely different specification. It standardizes some of the
authorization decisions a container makes. It works in tandem with JASPIC,
but is not required by it. I don't think it's needed to look at JACC for
this project.

Kind regards,
Arjan Tijms





>
> Thanks,
> Fjodor
>
> 2015-05-04 16:49 GMT+03:00 Arjan Tijms <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035882&i=0>>:
>
> > Hi,
> >
> > Great news!
> >
> > Do you have any definite start date for the actual coding already?
> >
> > A short while ago I did a very small and simple implementation of the
> > Servlet BASIC auth mechanism using JASPIC, which is one of the 4
> mechanisms
> > required by Servlet.
> >
> > See:
> >
> >
> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java
> >
> > Calling out to the "identity store" is however not standardised yet (the
> > example code simply uses CDI) and has to be done in a Tomcat specific
> way.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] <
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5035882&i=1>>
> wrote:
> >
> > > Good news, everyone!
> > > I am happy to announce that our project has been accepted to
> participate
> > > in
> > > GSoC. Now it's community binding period, so I need to introduce myself
> to
> > > other developers.
> > > Some brief information about me: My name is Fjodor Vershinin, I am
> 2'th
> > > grade computer science student from Estonia. One of my hobbies is
> writing
> > > OSS software, mainly in Java and Python. I hope to finish JASPIC
> > > implementation during this summer and make Tomcat better ;)
> > > Fjodor.
> > >
> > >
> > > 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5034072&i=0>>:
> > >
> > > > Hello!
> > > > It looks like ASF has been selected for GSOC 2015 and I am
> interested
> > in
> > > > pushing this project forward. So, in meantime I'll start writing
> > > proposal
> > > > and hope this project will be selected to participate in Gsoc
> program.
> > > > Best regards,
> > > > Fjodor.
> > > >
> > > > 2015-02-10 22:44 GMT+02:00 Arjan Tijms <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5034072&i=1>>:
> > > >
> > > >> Hi,
> > > >>
> > > >> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
> > > >> <[hidden email] <http://
> > /user/SendEmail.jtp?type=node&node=5034072&i=2>>
> > > wrote:
> > > >> > If you do look at JBoss keep in mind it is GPL licensed and we
> need
> > > to
> > > >> > be very careful that we don't end up with GPL'd code in Tomcat.
> > > >>
> > > >> That's absolutely true. The code there shouldn't not be copied in
> any
> > > >> way. It's only useful as an example of how a Tomcat Valve can
> > > >> integrate with something like JASPIC. As for the JASPIC code there,
> it
> > > >> wouldn't make sense to copy it anyway, since A) it's JBoss specific
> > > >> (builds up JBoss principal, calls JBoss security service, etc) and
> B)
> > > >> there are various issues with it (it looks like JBoss pretty much
> > > >> rewrote everything from scratch for Undertow, which is completely
> > > >> different).
> > > >>
> > > >> > Personally, I'd look more much more closely at Geronimo.
> > > >>
> > > >> You're right, and since that one is Apache licensed one can even
> copy
> > > >> from it if needed.
> > > >>
> > > >> > Keep in mind that part of the goal is to replace the existing
> > > >> > authenticators with JASPIC modules. (As suggested on the Servlet
> EG
> > > >> list.)
> > > >>
> > > >> It's good to have that as part of the goal indeed. Such auth
> modules
> > > >> could even be implemented by a separate (group) of students if
> needed,
> > > >> as they would not necessarily depend on the JASPIC implementation
> for
> > > >> Tomcat. As long as that one is not finished they could test it on
> any
> > > >> existing JASPIC implementation (e.g. the RI, GlassFish).
> > > >>
> > > >> > I think we all know that feeling - hence why I suggested it for
> > GSoC.
> > > >>
> > > >> Yeah, I get that, thanks! It's still something that I'd really love
> to
> > > >> do, but with the work for the startup zeef.com, open source
> projects
> > > >> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps
> soon
> > > >> for the security EG, there is not always much time left. I had this
> on
> > > >> my sketchy todo list for ~end of this month, but I'll see what
> happens
> > > >> with the GSoC project now ;)
> > > >>
> > > >> Kind regards,
> > > >> Arjan
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > Mark
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: [hidden email]
> > > >> > For additional commands, e-mail: [hidden email]
> > > >> >
> > > >> >
> > > >> >
> > > >> > ________________________________
> > > >> > If you reply to this email, your message will be added to the
> > > discussion
> > > >> > below:
> > > >> >
> > > >>
> > >
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> > > >> > To unsubscribe from Consider support for the Servlet profile of
> JSR
> > > 196
> > > >> > (JASPIC) in Tomcat 7.0.x, click here.
> > > >> > NAML
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
> > > >> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> > > >>
> > > >
> > > >
> > >
> > >
> > > ------------------------------
> > >  If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html
> > >  To unsubscribe from Consider support for the Servlet profile of JSR
> 196
> > > (JASPIC) in Tomcat 7.0.x, click here
> > > <
> > >
> > > .
> > > NAML
> > > <
> >
> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034079.html
> > Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> >
>
>
>
> --
> Thanks,
> Fjodor
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035882.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035885.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Wed, Jun 10, 2015 at 3:09 PM, markt [via Tomcat] <
ml-node+s10n5035886h42@n6.nabble.com> wrote:

> A Valve is certainly a likely candidate since the current Authenticator
> implementations are all Valves. It really depends on whether access is
> required to Tomcat's internals. If you need access to the internals, a
> Valve is probably the way to go. If the Servlet API is sufficient then a
> Filter may be an option. Depending on exactly what the integration
> points are there may be other options.


Traditionally it has not been really possible to implement JASPIC via the
Servlet API.

A requirement of JASPIC is that a SAM is called before the Servlet chain is
invoked, which is by definition not possible (Filters are part of that
chain).

Even if you relax the rules a little, then you'd need to make sure that the
Filter that's calling the SAM is absolutely guaranteed to be the very
first, with no possible way that any other Filter could be placed before it.

Then, via the standard Servlet API you cannot really establish the
authenticated identity. You can fake it a little by wrapping
HttpServletRequest and returning your own values for things like
isUserInRole, but you'd also have to process auth-constraints defined in
web.xml and @WebServlet annotations, which is quite hard to do from a
filter (you'd be duplicating the web.xml parsing and annotation scanning
from the Servlet container).

Also, a SAM should be called when HttpServletRequest.authenticate and
HttpServletRequest.logout is called from a Filter or Servlet.

Typically the best thing is that whatever kind of code the Servlet
container is already using to implement the standard authentication
mechanisms BASIC, FORM, etc is also used to implement JASPIC. I have to
double check, but if I'm not mistaken this is what most containers are
indeed doing.



> Is the configuration always going to be per web application (in which
> case context.xml is a likely candidate) or can it be per Host or per
> Engine (which suggests server.xml)?


There are two options in JASPIC:

1. Per web application.

Programmatically (from within the application) this is done by passing an
"appContextID" to the JASPIC factory that is used for registration. This
appContextID is computed as follows:

String getAppContextID(ServletContext context)
 return context.getVirtualServerName() + " " + context.getContextPath();
}

2. Globally for the entire container (all applications running on it).

Programmatically this is done by passing a null to the JASPIC factory.
Doing this from an application is maybe rare, but with it you could
theoretically "deploy" an authentication module to a server by deploying a
war that only contains the SAM and the registration code.



> Are there any 'standard'
> configuration files defined by JASPIC?
>

Nope. I more or less happened to mention this in my reply to Fjodor, but
there is not a single standard configuration file. The only standardized
way is by using the AuthConfigFactory.

Kind regards,
Arjan Tijms




>
> > And what about JACC support? Geronimo uses JACC for authorization
> config,
> > what about Tomcat?
>
> Tomcat currently uses Realms. It was not intended to implement JACC as
> part of the GSoC project. If the project goes well and the JASPIC work
> is completed early, taking a look at JACC would be a useful thing to do.
>
> Mark
>
>
> >
> > Thanks,
> > Fjodor
> >
> > 2015-05-04 16:49 GMT+03:00 Arjan Tijms <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035886&i=0>>:
> >
> >> Hi,
> >>
> >> Great news!
> >>
> >> Do you have any definite start date for the actual coding already?
> >>
> >> A short while ago I did a very small and simple implementation of the
> >> Servlet BASIC auth mechanism using JASPIC, which is one of the 4
> mechanisms
> >> required by Servlet.
> >>
> >> See:
> >>
> >>
> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java
> >>
> >> Calling out to the "identity store" is however not standardised yet
> (the
> >> example code simply uses CDI) and has to be done in a Tomcat specific
> way.
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >> On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] <
> >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=5035886&i=1>>
> wrote:
> >>
> >>> Good news, everyone!
> >>> I am happy to announce that our project has been accepted to
> participate
> >>> in
> >>> GSoC. Now it's community binding period, so I need to introduce myself
> to
> >>> other developers.
> >>> Some brief information about me: My name is Fjodor Vershinin, I am
> 2'th
> >>> grade computer science student from Estonia. One of my hobbies is
> writing
> >>> OSS software, mainly in Java and Python. I hope to finish JASPIC
> >>> implementation during this summer and make Tomcat better ;)
> >>> Fjodor.
> >>>
> >>>
> >>> 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <[hidden email]
> >>> <http:///user/SendEmail.jtp?type=node&node=5034072&i=0>>:
> >>>
> >>>> Hello!
> >>>> It looks like ASF has been selected for GSOC 2015 and I am interested
> >> in
> >>>> pushing this project forward. So, in meantime I'll start writing
> >>> proposal
> >>>> and hope this project will be selected to participate in Gsoc
> program.
> >>>> Best regards,
> >>>> Fjodor.
> >>>>
> >>>> 2015-02-10 22:44 GMT+02:00 Arjan Tijms <[hidden email]
> >>> <http:///user/SendEmail.jtp?type=node&node=5034072&i=1>>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
> >>>>> <[hidden email] <http://
> >> /user/SendEmail.jtp?type=node&node=5034072&i=2>>
> >>> wrote:
> >>>>>> If you do look at JBoss keep in mind it is GPL licensed and we need
> >>> to
> >>>>>> be very careful that we don't end up with GPL'd code in Tomcat.
> >>>>>
> >>>>> That's absolutely true. The code there shouldn't not be copied in
> any
> >>>>> way. It's only useful as an example of how a Tomcat Valve can
> >>>>> integrate with something like JASPIC. As for the JASPIC code there,
> it
> >>>>> wouldn't make sense to copy it anyway, since A) it's JBoss specific
> >>>>> (builds up JBoss principal, calls JBoss security service, etc) and
> B)
> >>>>> there are various issues with it (it looks like JBoss pretty much
> >>>>> rewrote everything from scratch for Undertow, which is completely
> >>>>> different).
> >>>>>
> >>>>>> Personally, I'd look more much more closely at Geronimo.
> >>>>>
> >>>>> You're right, and since that one is Apache licensed one can even
> copy
> >>>>> from it if needed.
> >>>>>
> >>>>>> Keep in mind that part of the goal is to replace the existing
> >>>>>> authenticators with JASPIC modules. (As suggested on the Servlet EG
> >>>>> list.)
> >>>>>
> >>>>> It's good to have that as part of the goal indeed. Such auth modules
> >>>>> could even be implemented by a separate (group) of students if
> needed,
> >>>>> as they would not necessarily depend on the JASPIC implementation
> for
> >>>>> Tomcat. As long as that one is not finished they could test it on
> any
> >>>>> existing JASPIC implementation (e.g. the RI, GlassFish).
> >>>>>
> >>>>>> I think we all know that feeling - hence why I suggested it for
> >> GSoC.
> >>>>>
> >>>>> Yeah, I get that, thanks! It's still something that I'd really love
> to
> >>>>> do, but with the work for the startup zeef.com, open source
> projects
> >>>>> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
> >>>>> for the security EG, there is not always much time left. I had this
> on
> >>>>> my sketchy todo list for ~end of this month, but I'll see what
> happens
> >>>>> with the GSoC project now ;)
> >>>>>
> >>>>> Kind regards,
> >>>>> Arjan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ________________________________
> >>>>>> If you reply to this email, your message will be added to the
> >>> discussion
> >>>>>> below:
> >>>>>>
> >>>>>
> >>>
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> >>>>>> To unsubscribe from Consider support for the Servlet profile of JSR
> >>> 196
> >>>>>> (JASPIC) in Tomcat 7.0.x, click here.
> >>>>>> NAML
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> >>>
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
> >>>>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> ------------------------------
> >>>  If you reply to this email, your message will be added to the
> discussion
> >>> below:
> >>>
> >>>
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html
> >>>  To unsubscribe from Consider support for the Servlet profile of JSR
> 196
> >>> (JASPIC) in Tomcat 7.0.x, click here
> >>> <
> >>
> >>> .
> >>> NAML
> >>> <
> >>
> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034079.html
> >> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035886&i=2>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5035886&i=3>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035886.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035890.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Vershinin <fj...@vershinin.net>.

Hi, David!

> Is the hope that these existing forms of auth will be ported and plugged
> in through the JASPIC support?  That would be quite excellent if so.
>
Yes, this is our main goal, actually. Implementing JASPIC is only part of
my GSOC project.
 --
Thanks,
Fjodor

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by David Blevins <da...@gmail.com>.

Hi folks!  Great to see this thread picking up steam.

On Jun 10, 2015, at 6:12 AM, Mark Thomas <ma...@apache.org> wrote:

> On 10/06/2015 13:34, Fjodor Vershinin wrote:
> 
>> And what about code backward compatibility for Geronimo,
>> should code ported back, or new Geronimo release can use our
>> implementation?
> 
> Re-use by downstream consumers of Tomcat like TomEE and Geronimo is
> certainly a goal. The TomEE folks tend to provide feedback when we do
> something that makes their life difficult so I'd expect them to speak up
> if they spot a problem.

We'll happily be waiting for the code upstream. :)

> I wouldn't worry about backwards compatibility for Geronimo. That would
> probably be difficult to achieve. Keep in mind that Geronimo may wish to
> re-use the code (or just some of the patches) but if you need to change
> something you should feel free to do so.

Agree.  I'd focus on making the code as tight and clean as possible.

On Jun 10, 2015, at 6:31 AM, Mark Thomas <ma...@apache.org> wrote:

> On 10/06/2015 14:04, Arjan Tijms wrote:
> 
>> Tomcat already has some dedicated configuration files for this.
> 
> My expectation is that all of Tomcat's existing authentication
> mechanisms would be made available at the container level (BASIC,
> DIGEST, FORM, CLIENT-CERT, SPNEGO).
> 
> It should be a small step from there to replacing Tomcat's current
> authenticators with the appropriate JASPIC config.

Is the hope that these existing forms of auth will be ported and plugged in through the JASPIC support?  That would be quite excellent if so.


-David


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 10/06/2015 13:34, Fjodor Vershinin wrote:
> Hi, guys!

"guys" can be taken as referring to men only. Something like the gender
neutral "all" would be more inclusive.

> This week goal is to replace current valve based authentication with JASPIC
> based mechanism. It is what I am currently working on.

Could you expand on what exactly you are aiming for this week? The
sentence above sounds more like the aim for the entire project.

> From my research Geronimo's implementation is also based on tomcat's
> valves, and it's pretty straightforward how to integrate SecurityValve into
> Tomcat's codebase. However, I am not sure, is that correct way? Do you have
> better ideas?

It is hard to be definite without knowing what the integration points
are. Can you expand on this?

A Valve is certainly a likely candidate since the current Authenticator
implementations are all Valves. It really depends on whether access is
required to Tomcat's internals. If you need access to the internals, a
Valve is probably the way to go. If the Servlet API is sufficient then a
Filter may be an option. Depending on exactly what the integration
points are there may be other options.

> And what about code backward compatibility for Geronimo,
> should code ported back, or new Geronimo release can use our
> implementation?

Re-use by downstream consumers of Tomcat like TomEE and Geronimo is
certainly a goal. The TomEE folks tend to provide feedback when we do
something that makes their life difficult so I'd expect them to speak up
if they spot a problem. Anything that works for TomEE should work for
Geronimo.

I wouldn't worry about backwards compatibility for Geronimo. That would
probably be difficult to achieve. Keep in mind that Geronimo may wish to
re-use the code (or just some of the patches) but if you need to change
something you should feel free to do so.

> We are implementing JASPIC 1.1, and there will be quite a
> lot changes anyway. Also, Geronimo uses OSGi framework in their code, which
> must be dropped off, because Tomcat is not OSGi based.

Without knowing how much OSGi code there is in the Geronimo
implementation, if there is scope for appropriate use of factories,
service loaders etc. to make it relatively easy to insert the necessary
OSGi changes for those downstream users that will want to then we should
try to do so.

> What about JASPIC configuration, I am curious, where we want to hold
> configuration files. Different vendors use special xml files, for example
> geronimo-web.xml, for configuring realms and other security stuff. Do we
> need something like tomcat-web.xml?

Is the configuration always going to be per web application (in which
case context.xml is a likely candidate) or can it be per Host or per
Engine (which suggests server.xml)? Are there any 'standard'
configuration files defined by JASPIC?

> And what about JACC support? Geronimo uses JACC for authorization config,
> what about Tomcat?

Tomcat currently uses Realms. It was not intended to implement JACC as
part of the GSoC project. If the project goes well and the JASPIC work
is completed early, taking a look at JACC would be a useful thing to do.

Mark


> 
> Thanks,
> Fjodor
> 
> 2015-05-04 16:49 GMT+03:00 Arjan Tijms <ar...@gmail.com>:
> 
>> Hi,
>>
>> Great news!
>>
>> Do you have any definite start date for the actual coding already?
>>
>> A short while ago I did a very small and simple implementation of the
>> Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms
>> required by Servlet.
>>
>> See:
>>
>> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java
>>
>> Calling out to the "identity store" is however not standardised yet (the
>> example code simply uses CDI) and has to be done in a Tomcat specific way.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>> On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] <
>> ml-node+s10n5034072h8@n6.nabble.com> wrote:
>>
>>> Good news, everyone!
>>> I am happy to announce that our project has been accepted to participate
>>> in
>>> GSoC. Now it's community binding period, so I need to introduce myself to
>>> other developers.
>>> Some brief information about me: My name is Fjodor Vershinin, I am 2'th
>>> grade computer science student from Estonia. One of my hobbies is writing
>>> OSS software, mainly in Java and Python. I hope to finish JASPIC
>>> implementation during this summer and make Tomcat better ;)
>>> Fjodor.
>>>
>>>
>>> 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=5034072&i=0>>:
>>>
>>>> Hello!
>>>> It looks like ASF has been selected for GSOC 2015 and I am interested
>> in
>>>> pushing this project forward. So, in meantime I'll start writing
>>> proposal
>>>> and hope this project will be selected to participate in Gsoc program.
>>>> Best regards,
>>>> Fjodor.
>>>>
>>>> 2015-02-10 22:44 GMT+02:00 Arjan Tijms <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=5034072&i=1>>:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
>>>>> <[hidden email] <http://
>> /user/SendEmail.jtp?type=node&node=5034072&i=2>>
>>> wrote:
>>>>>> If you do look at JBoss keep in mind it is GPL licensed and we need
>>> to
>>>>>> be very careful that we don't end up with GPL'd code in Tomcat.
>>>>>
>>>>> That's absolutely true. The code there shouldn't not be copied in any
>>>>> way. It's only useful as an example of how a Tomcat Valve can
>>>>> integrate with something like JASPIC. As for the JASPIC code there, it
>>>>> wouldn't make sense to copy it anyway, since A) it's JBoss specific
>>>>> (builds up JBoss principal, calls JBoss security service, etc) and B)
>>>>> there are various issues with it (it looks like JBoss pretty much
>>>>> rewrote everything from scratch for Undertow, which is completely
>>>>> different).
>>>>>
>>>>>> Personally, I'd look more much more closely at Geronimo.
>>>>>
>>>>> You're right, and since that one is Apache licensed one can even copy
>>>>> from it if needed.
>>>>>
>>>>>> Keep in mind that part of the goal is to replace the existing
>>>>>> authenticators with JASPIC modules. (As suggested on the Servlet EG
>>>>> list.)
>>>>>
>>>>> It's good to have that as part of the goal indeed. Such auth modules
>>>>> could even be implemented by a separate (group) of students if needed,
>>>>> as they would not necessarily depend on the JASPIC implementation for
>>>>> Tomcat. As long as that one is not finished they could test it on any
>>>>> existing JASPIC implementation (e.g. the RI, GlassFish).
>>>>>
>>>>>> I think we all know that feeling - hence why I suggested it for
>> GSoC.
>>>>>
>>>>> Yeah, I get that, thanks! It's still something that I'd really love to
>>>>> do, but with the work for the startup zeef.com, open source projects
>>>>> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
>>>>> for the security EG, there is not always much time left. I had this on
>>>>> my sketchy todo list for ~end of this month, but I'll see what happens
>>>>> with the GSoC project now ;)
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>> If you reply to this email, your message will be added to the
>>> discussion
>>>>>> below:
>>>>>>
>>>>>
>>>
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
>>>>>> To unsubscribe from Consider support for the Servlet profile of JSR
>>> 196
>>>>>> (JASPIC) in Tomcat 7.0.x, click here.
>>>>>> NAML
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
>>>>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------
>>>  If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>>
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html
>>>  To unsubscribe from Consider support for the Servlet profile of JSR 196
>>> (JASPIC) in Tomcat 7.0.x, click here
>>> <
>> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
>>>
>>> .
>>> NAML
>>> <
>> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>>>
>>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034079.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Vershinin <fj...@vershinin.net>.

Hi, guys!
This week goal is to replace current valve based authentication with JASPIC
based mechanism. It is what I am currently working on.
>From my research Geronimo's implementation is also based on tomcat's
valves, and it's pretty straightforward how to integrate SecurityValve into
Tomcat's codebase. However, I am not sure, is that correct way? Do you have
better ideas? And what about code backward compatibility for Geronimo,
should code ported back, or new Geronimo release can use our
implementation? We are implementing JASPIC 1.1, and there will be quite a
lot changes anyway. Also, Geronimo uses OSGi framework in their code, which
must be dropped off, because Tomcat is not OSGi based.
What about JASPIC configuration, I am curious, where we want to hold
configuration files. Different vendors use special xml files, for example
geronimo-web.xml, for configuring realms and other security stuff. Do we
need something like tomcat-web.xml?
And what about JACC support? Geronimo uses JACC for authorization config,
what about Tomcat?

Thanks,
Fjodor

2015-05-04 16:49 GMT+03:00 Arjan Tijms <ar...@gmail.com>:

> Hi,
>
> Great news!
>
> Do you have any definite start date for the actual coding already?
>
> A short while ago I did a very small and simple implementation of the
> Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms
> required by Servlet.
>
> See:
>
> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java
>
> Calling out to the "identity store" is however not standardised yet (the
> example code simply uses CDI) and has to be done in a Tomcat specific way.
>
> Kind regards,
> Arjan Tijms
>
>
> On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] <
> ml-node+s10n5034072h8@n6.nabble.com> wrote:
>
> > Good news, everyone!
> > I am happy to announce that our project has been accepted to participate
> > in
> > GSoC. Now it's community binding period, so I need to introduce myself to
> > other developers.
> > Some brief information about me: My name is Fjodor Vershinin, I am 2'th
> > grade computer science student from Estonia. One of my hobbies is writing
> > OSS software, mainly in Java and Python. I hope to finish JASPIC
> > implementation during this summer and make Tomcat better ;)
> > Fjodor.
> >
> >
> > 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=5034072&i=0>>:
> >
> > > Hello!
> > > It looks like ASF has been selected for GSOC 2015 and I am interested
> in
> > > pushing this project forward. So, in meantime I'll start writing
> > proposal
> > > and hope this project will be selected to participate in Gsoc program.
> > > Best regards,
> > > Fjodor.
> > >
> > > 2015-02-10 22:44 GMT+02:00 Arjan Tijms <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=5034072&i=1>>:
> > >
> > >> Hi,
> > >>
> > >> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
> > >> <[hidden email] <http://
> /user/SendEmail.jtp?type=node&node=5034072&i=2>>
> > wrote:
> > >> > If you do look at JBoss keep in mind it is GPL licensed and we need
> > to
> > >> > be very careful that we don't end up with GPL'd code in Tomcat.
> > >>
> > >> That's absolutely true. The code there shouldn't not be copied in any
> > >> way. It's only useful as an example of how a Tomcat Valve can
> > >> integrate with something like JASPIC. As for the JASPIC code there, it
> > >> wouldn't make sense to copy it anyway, since A) it's JBoss specific
> > >> (builds up JBoss principal, calls JBoss security service, etc) and B)
> > >> there are various issues with it (it looks like JBoss pretty much
> > >> rewrote everything from scratch for Undertow, which is completely
> > >> different).
> > >>
> > >> > Personally, I'd look more much more closely at Geronimo.
> > >>
> > >> You're right, and since that one is Apache licensed one can even copy
> > >> from it if needed.
> > >>
> > >> > Keep in mind that part of the goal is to replace the existing
> > >> > authenticators with JASPIC modules. (As suggested on the Servlet EG
> > >> list.)
> > >>
> > >> It's good to have that as part of the goal indeed. Such auth modules
> > >> could even be implemented by a separate (group) of students if needed,
> > >> as they would not necessarily depend on the JASPIC implementation for
> > >> Tomcat. As long as that one is not finished they could test it on any
> > >> existing JASPIC implementation (e.g. the RI, GlassFish).
> > >>
> > >> > I think we all know that feeling - hence why I suggested it for
> GSoC.
> > >>
> > >> Yeah, I get that, thanks! It's still something that I'd really love to
> > >> do, but with the work for the startup zeef.com, open source projects
> > >> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
> > >> for the security EG, there is not always much time left. I had this on
> > >> my sketchy todo list for ~end of this month, but I'll see what happens
> > >> with the GSoC project now ;)
> > >>
> > >> Kind regards,
> > >> Arjan
> > >>
> > >>
> > >>
> > >>
> > >> >
> > >> > Mark
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: [hidden email]
> > >> > For additional commands, e-mail: [hidden email]
> > >> >
> > >> >
> > >> >
> > >> > ________________________________
> > >> > If you reply to this email, your message will be added to the
> > discussion
> > >> > below:
> > >> >
> > >>
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> > >> > To unsubscribe from Consider support for the Servlet profile of JSR
> > 196
> > >> > (JASPIC) in Tomcat 7.0.x, click here.
> > >> > NAML
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
> > >> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> > >>
> > >
> > >
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html
> >  To unsubscribe from Consider support for the Servlet profile of JSR 196
> > (JASPIC) in Tomcat 7.0.x, click here
> > <
> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
> >
> > .
> > NAML
> > <
> http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034079.html
> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>



-- 
Thanks,
Fjodor

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

Great news!

Do you have any definite start date for the actual coding already?

A short while ago I did a very small and simple implementation of the
Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms
required by Servlet.

See:
https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java

Calling out to the "identity store" is however not standardised yet (the
example code simply uses CDI) and has to be done in a Tomcat specific way.

Kind regards,
Arjan Tijms


On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] <
ml-node+s10n5034072h8@n6.nabble.com> wrote:

> Good news, everyone!
> I am happy to announce that our project has been accepted to participate
> in
> GSoC. Now it's community binding period, so I need to introduce myself to
> other developers.
> Some brief information about me: My name is Fjodor Vershinin, I am 2'th
> grade computer science student from Estonia. One of my hobbies is writing
> OSS software, mainly in Java and Python. I hope to finish JASPIC
> implementation during this summer and make Tomcat better ;)
> Fjodor.
>
>
> 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5034072&i=0>>:
>
> > Hello!
> > It looks like ASF has been selected for GSOC 2015 and I am interested in
> > pushing this project forward. So, in meantime I'll start writing
> proposal
> > and hope this project will be selected to participate in Gsoc program.
> > Best regards,
> > Fjodor.
> >
> > 2015-02-10 22:44 GMT+02:00 Arjan Tijms <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5034072&i=1>>:
> >
> >> Hi,
> >>
> >> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
> >> <[hidden email] <http:///user/SendEmail.jtp?type=node&node=5034072&i=2>>
> wrote:
> >> > If you do look at JBoss keep in mind it is GPL licensed and we need
> to
> >> > be very careful that we don't end up with GPL'd code in Tomcat.
> >>
> >> That's absolutely true. The code there shouldn't not be copied in any
> >> way. It's only useful as an example of how a Tomcat Valve can
> >> integrate with something like JASPIC. As for the JASPIC code there, it
> >> wouldn't make sense to copy it anyway, since A) it's JBoss specific
> >> (builds up JBoss principal, calls JBoss security service, etc) and B)
> >> there are various issues with it (it looks like JBoss pretty much
> >> rewrote everything from scratch for Undertow, which is completely
> >> different).
> >>
> >> > Personally, I'd look more much more closely at Geronimo.
> >>
> >> You're right, and since that one is Apache licensed one can even copy
> >> from it if needed.
> >>
> >> > Keep in mind that part of the goal is to replace the existing
> >> > authenticators with JASPIC modules. (As suggested on the Servlet EG
> >> list.)
> >>
> >> It's good to have that as part of the goal indeed. Such auth modules
> >> could even be implemented by a separate (group) of students if needed,
> >> as they would not necessarily depend on the JASPIC implementation for
> >> Tomcat. As long as that one is not finished they could test it on any
> >> existing JASPIC implementation (e.g. the RI, GlassFish).
> >>
> >> > I think we all know that feeling - hence why I suggested it for GSoC.
> >>
> >> Yeah, I get that, thanks! It's still something that I'd really love to
> >> do, but with the work for the startup zeef.com, open source projects
> >> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
> >> for the security EG, there is not always much time left. I had this on
> >> my sketchy todo list for ~end of this month, but I'll see what happens
> >> with the GSoC project now ;)
> >>
> >> Kind regards,
> >> Arjan
> >>
> >>
> >>
> >>
> >> >
> >> > Mark
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
> >> >
> >> > ________________________________
> >> > If you reply to this email, your message will be added to the
> discussion
> >> > below:
> >> >
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> >> > To unsubscribe from Consider support for the Servlet profile of JSR
> 196
> >> > (JASPIC) in Tomcat 7.0.x, click here.
> >> > NAML
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
> >> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
> >>
> >
> >
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034079.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

Fjodor, for you (and everyone else interested) I've created a central hub
page for JASPIC on ZEEF.com, see https://jaspic.zeef.com

It contains links to existing implementations, various examples, articles,
and background.

Hope it helps!

Kind regards,
Arjan Tijms


On Mon, May 4, 2015 at 10:06 PM, Mark Thomas-2 [via Tomcat] <
ml-node+s10n5034096h52@n6.nabble.com> wrote:

> On 04/05/2015 10:49, Fjodor Vershinin wrote:
> > Good news, everyone!
> > I am happy to announce that our project has been accepted to participate
> in
> > GSoC. Now it's community binding period, so I need to introduce myself
> to
> > other developers.
> > Some brief information about me: My name is Fjodor Vershinin, I am 2'th
> > grade computer science student from Estonia. One of my hobbies is
> writing
> > OSS software, mainly in Java and Python. I hope to finish JASPIC
> > implementation during this summer and make Tomcat better ;)
> > Fjodor.
>
> That is good news. Welcome to the Tomcat community.
>
> A good way to get to know the community better is to work on some simple
> bug fixes. You are welcome to choose one yourself or you, if you prefer
> a recommendation, I suggest bug 57665. If you do opt to look at bug
> 57665, you might find my recent fix for bug 57856 (r1676364) informative.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5034096&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5034096&i=1>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034096.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034845.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 04/05/2015 10:49, Fjodor Vershinin wrote:
> Good news, everyone!
> I am happy to announce that our project has been accepted to participate in
> GSoC. Now it's community binding period, so I need to introduce myself to
> other developers.
> Some brief information about me: My name is Fjodor Vershinin, I am 2'th
> grade computer science student from Estonia. One of my hobbies is writing
> OSS software, mainly in Java and Python. I hope to finish JASPIC
> implementation during this summer and make Tomcat better ;)
> Fjodor.

That is good news. Welcome to the Tomcat community.

A good way to get to know the community better is to work on some simple
bug fixes. You are welcome to choose one yourself or you, if you prefer
a recommendation, I suggest bug 57665. If you do opt to look at bug
57665, you might find my recent fix for bug 57856 (r1676364) informative.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Vershinin <fj...@vershinin.net>.

Good news, everyone!
I am happy to announce that our project has been accepted to participate in
GSoC. Now it's community binding period, so I need to introduce myself to
other developers.
Some brief information about me: My name is Fjodor Vershinin, I am 2'th
grade computer science student from Estonia. One of my hobbies is writing
OSS software, mainly in Java and Python. I hope to finish JASPIC
implementation during this summer and make Tomcat better ;)
Fjodor.


2015-03-04 11:09 GMT+02:00 Fjodor Vershinin <fj...@vershinin.net>:

> Hello!
> It looks like ASF has been selected for GSOC 2015 and I am interested in
> pushing this project forward. So, in meantime I'll start writing proposal
> and hope this project will be selected to participate in Gsoc program.
> Best regards,
> Fjodor.
>
> 2015-02-10 22:44 GMT+02:00 Arjan Tijms <ar...@gmail.com>:
>
>> Hi,
>>
>> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
>> <ml...@n6.nabble.com> wrote:
>> > If you do look at JBoss keep in mind it is GPL licensed and we need to
>> > be very careful that we don't end up with GPL'd code in Tomcat.
>>
>> That's absolutely true. The code there shouldn't not be copied in any
>> way. It's only useful as an example of how a Tomcat Valve can
>> integrate with something like JASPIC. As for the JASPIC code there, it
>> wouldn't make sense to copy it anyway, since A) it's JBoss specific
>> (builds up JBoss principal, calls JBoss security service, etc) and B)
>> there are various issues with it (it looks like JBoss pretty much
>> rewrote everything from scratch for Undertow, which is completely
>> different).
>>
>> > Personally, I'd look more much more closely at Geronimo.
>>
>> You're right, and since that one is Apache licensed one can even copy
>> from it if needed.
>>
>> > Keep in mind that part of the goal is to replace the existing
>> > authenticators with JASPIC modules. (As suggested on the Servlet EG
>> list.)
>>
>> It's good to have that as part of the goal indeed. Such auth modules
>> could even be implemented by a separate (group) of students if needed,
>> as they would not necessarily depend on the JASPIC implementation for
>> Tomcat. As long as that one is not finished they could test it on any
>> existing JASPIC implementation (e.g. the RI, GlassFish).
>>
>> > I think we all know that feeling - hence why I suggested it for GSoC.
>>
>> Yeah, I get that, thanks! It's still something that I'd really love to
>> do, but with the work for the startup zeef.com, open source projects
>> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
>> for the security EG, there is not always much time left. I had this on
>> my sketchy todo list for ~end of this month, but I'll see what happens
>> with the GSoC project now ;)
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>> >
>> > Mark
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>> >
>> > ________________________________
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> >
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
>> > To unsubscribe from Consider support for the Servlet profile of JSR 196
>> > (JASPIC) in Tomcat 7.0.x, click here.
>> > NAML
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
>
>

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Fjodor Vershinin <fj...@vershinin.net>.

Hello!
It looks like ASF has been selected for GSOC 2015 and I am interested in
pushing this project forward. So, in meantime I'll start writing proposal
and hope this project will be selected to participate in Gsoc program.
Best regards,
Fjodor.

2015-02-10 22:44 GMT+02:00 Arjan Tijms <ar...@gmail.com>:

> Hi,
>
> On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
> <ml...@n6.nabble.com> wrote:
> > If you do look at JBoss keep in mind it is GPL licensed and we need to
> > be very careful that we don't end up with GPL'd code in Tomcat.
>
> That's absolutely true. The code there shouldn't not be copied in any
> way. It's only useful as an example of how a Tomcat Valve can
> integrate with something like JASPIC. As for the JASPIC code there, it
> wouldn't make sense to copy it anyway, since A) it's JBoss specific
> (builds up JBoss principal, calls JBoss security service, etc) and B)
> there are various issues with it (it looks like JBoss pretty much
> rewrote everything from scratch for Undertow, which is completely
> different).
>
> > Personally, I'd look more much more closely at Geronimo.
>
> You're right, and since that one is Apache licensed one can even copy
> from it if needed.
>
> > Keep in mind that part of the goal is to replace the existing
> > authenticators with JASPIC modules. (As suggested on the Servlet EG
> list.)
>
> It's good to have that as part of the goal indeed. Such auth modules
> could even be implemented by a separate (group) of students if needed,
> as they would not necessarily depend on the JASPIC implementation for
> Tomcat. As long as that one is not finished they could test it on any
> existing JASPIC implementation (e.g. the RI, GlassFish).
>
> > I think we all know that feeling - hence why I suggested it for GSoC.
>
> Yeah, I get that, thanks! It's still something that I'd really love to
> do, but with the work for the startup zeef.com, open source projects
> OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
> for the security EG, there is not always much time left. I had this on
> my sketchy todo list for ~end of this month, but I'll see what happens
> with the GSoC project now ;)
>
> Kind regards,
> Arjan
>
>
>
>
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ________________________________
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> > To unsubscribe from Consider support for the Servlet profile of JSR 196
> > (JASPIC) in Tomcat 7.0.x, click here.
> > NAML
>
>
>
>
> --
> View this message in context:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
<ml...@n6.nabble.com> wrote:
> If you do look at JBoss keep in mind it is GPL licensed and we need to
> be very careful that we don't end up with GPL'd code in Tomcat.

That's absolutely true. The code there shouldn't not be copied in any
way. It's only useful as an example of how a Tomcat Valve can
integrate with something like JASPIC. As for the JASPIC code there, it
wouldn't make sense to copy it anyway, since A) it's JBoss specific
(builds up JBoss principal, calls JBoss security service, etc) and B)
there are various issues with it (it looks like JBoss pretty much
rewrote everything from scratch for Undertow, which is completely
different).

> Personally, I'd look more much more closely at Geronimo.

You're right, and since that one is Apache licensed one can even copy
from it if needed.

> Keep in mind that part of the goal is to replace the existing
> authenticators with JASPIC modules. (As suggested on the Servlet EG list.)

It's good to have that as part of the goal indeed. Such auth modules
could even be implemented by a separate (group) of students if needed,
as they would not necessarily depend on the JASPIC implementation for
Tomcat. As long as that one is not finished they could test it on any
existing JASPIC implementation (e.g. the RI, GlassFish).

> I think we all know that feeling - hence why I suggested it for GSoC.

Yeah, I get that, thanks! It's still something that I'd really love to
do, but with the work for the startup zeef.com, open source projects
OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon
for the security EG, there is not always much time left. I had this on
my sketchy todo list for ~end of this month, but I'll see what happens
with the GSoC project now ;)

Kind regards,
Arjan

>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html
> To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here.
> NAML

--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Mark Thomas <ma...@apache.org>.

On 10/02/2015 18:42, Arjan Tijms wrote:
> Hi,
> 
> On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat] <
> ml-node+s10n5029627h13@n6.nabble.com> wrote:
> 
>> Hello!
>> I am CS student and it looks like that this task is quite interesting. I
>> would take it for GSOC if ASF organization will be selected. Currently I
>> have some time to do research in Tomcat codebase. Could you provide me some
>> entry points?
> 
> 
> Thanks for your interest in this. An entry point could be my original
> JASPIC article that you can find here;
> http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html
> 
> At the end of the article you'll find a list of resources.
> 
> My approach would be to investigate how Tomcat integrates authentication
> modules, eg look at the source of the JAAS support in Tomcat; that code has
> to do similar integration. You can look at JBoss 7.x for an example too, it
> used Tomcat and an integration Valve (WebJaspiAuthenticator seehttp://
> grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-web/7.1.1.Final/org/jboss/as/web/security/jaspi/WebJASPIAuthenticator.java

If you do look at JBoss keep in mind it is GPL licensed and we need to
be very careful that we don't end up with GPL'd code in Tomcat.

> )
> 
> Geronimo also implemented JASPIC and used Tomcat, so that implementation
> would be high on the list to study too.

Personally, I'd look more much more closely at Geronimo.

Keep in mind that part of the goal is to replace the existing
authenticators with JASPIC modules. (As suggested on the Servlet EG list.)

> Many implementations have a (large) part of their code dedicated to
> handling some xml file where jaspic auth modules are defined. Strictly
> speaking this is not a required part of JASPIC, but it's somewhat expected
> for configuring modules at the container side (as apposed to from within
> the app archive).

Tomcat already has a lot of the infrastructure for handling this sort of
thing. It could be as simple as adding a few digester rules.

> I did actually more or less promise to do this implementation myself, but
> so far havent found the time for it.

I think we all know that feeling - hence why I suggested it for GSoC.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

Posted by Arjan Tijms <ar...@gmail.com>.

Hi,

On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat] <
ml-node+s10n5029627h13@n6.nabble.com> wrote:

> Hello!
> I am CS student and it looks like that this task is quite interesting. I
> would take it for GSOC if ASF organization will be selected. Currently I
> have some time to do research in Tomcat codebase. Could you provide me some
> entry points?

Thanks for your interest in this. An entry point could be my original
JASPIC article that you can find here;
http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html

At the end of the article you'll find a list of resources.

My approach would be to investigate how Tomcat integrates authentication
modules, eg look at the source of the JAAS support in Tomcat; that code has
to do similar integration. You can look at JBoss 7.x for an example too, it
used Tomcat and an integration Valve (WebJaspiAuthenticator seehttp://
grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-web/7.1.1.Final/org/jboss/as/web/security/jaspi/WebJASPIAuthenticator.java
)

Geronimo also implemented JASPIC and used Tomcat, so that implementation
would be high on the list to study too.

Many implementations have a (large) part of their code dedicated to
handling some xml file where jaspic auth modules are defined. Strictly
speaking this is not a required part of JASPIC, but it's somewhat expected
for configuring modules at the container side (as apposed to from within
the app archive).

I did actually more or less promise to do this implementation myself, but
so far havent found the time for it.

Let me know if this is enough to get started.

Kind regards,
Arjan

> Thanks,
> Fjodor
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029627.html
>  To unsubscribe from Consider support for the Servlet profile of JSR 196
> (JASPIC) in Tomcat 7.0.x, click here
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4993387&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==>
> .
> NAML
> <http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029633.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.