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

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

2015-12-04 Thread Arjan Tijms

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

2015-10-20 Thread Fjodor Vershinin

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 :

> 2015-10-16 17:18 GMT+02:00 Arjan Tijms :
>
> > On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
> >  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

2015-10-20 Thread Rémy Maucherat

2015-10-20 8:18 GMT+02:00 Fjodor Vershinin :

> 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

2015-10-16 Thread Rémy Maucherat

2015-10-16 17:18 GMT+02:00 Arjan Tijms :

> On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
>  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

2015-10-16 Thread Rémy Maucherat

2015-10-15 3:03 GMT+02:00 Fjodor Versinin :

> 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

2015-10-16 Thread Mark Thomas

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.

Mark

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

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

2015-10-16 Thread Jess Holle


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-10-16 Thread Arjan Tijms

Hi,

On Fri, Oct 16, 2015 at 12:56 PM, Jess Holle [via Tomcat]
 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

2015-10-16 Thread Rémy Maucherat

2015-10-16 12:51 GMT+02:00 Mark Thomas :

> 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

2015-10-16 Thread Rémy Maucherat

2015-10-16 13:25 GMT+02:00 Arjan Tijms :

> 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

2015-10-16 Thread Arjan Tijms

On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
 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

2015-10-16 Thread Arjan Tijms

Hi,

On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat]
 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

2015-10-16 Thread Rémy Maucherat

2015-10-16 16:11 GMT+02:00 Arjan Tijms :

> Hi,
>
> On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat]
>  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

2015-10-15 Thread Mark Thomas

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-10-14 Thread gradstud

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.ti...@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] 
 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] 
>>> 
>>> 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-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
>>>
>>> >> _viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.names
>>> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble
>>> .view.web.template.NodeNamespace=notify_subscribers%21na
>>> bble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_
>>> email%21nabble%3Aemail.naml>
>>>
>>
>>
>>
>>
>>

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

2015-10-14 Thread Fjodor Versinin

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

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

2015-10-14 Thread Arjan Tijms

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]
 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]
>>> 
>>> 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-tp4993387p5035887.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-tp4993387p5035891.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail:

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

2015-10-14 Thread Mark Thomas

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]
>  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]
 
 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-tp4993387p5035887.html
  To unsubscribe from Consider support for the Servlet profile of JSR 196
 (JASPIC) in Tomcat 7.0.x, click here
 <
 .
 NAML

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

2015-06-11 Thread Mark Thomas

On 10/06/2015 16:43, Arjan Tijms wrote:
 Hi,
 
 On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] 
 ml-node+s10n5035887...@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=nodenode=5035887i=0
 For additional commands, e-mail: [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=5035887i=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_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
 .
 NAML
 http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-06-11 Thread Fjodor Vershinin

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

2015-06-10 Thread Fjodor Vershinin

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 arjan.ti...@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+s10n503407...@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=nodenode=5034072i=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=nodenode=5034072i=1:

Hi,

On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
[hidden email] http://
/user/SendEmail.jtp?type=nodenode=5034072i=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]

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

2015-06-10 Thread Arjan Tijms

Hi,

On Wed, Jun 10, 2015 at 2:31 PM, Fjodor Vershinin [via Tomcat]
ml-node+s10n5035882...@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=nodenode=5035882i=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=nodenode=5035882i=1
wrote:

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

2015-06-10 Thread Mark Thomas

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 arjan.ti...@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+s10n503407...@n6.nabble.com wrote:

2015-03-04 11:09 GMT+02:00 Fjodor Vershinin [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5034072i=0:

2015-02-10 22:44 GMT+02:00 Arjan Tijms [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5034072i=1:

Hi,

On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
[hidden email] http://

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

2015-06-10 Thread Mark Thomas

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-06-10 Thread Arjan Tijms

Hi,

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

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?

Mark

Thanks,
Fjodor

2015-05-04 16:49 GMT+03:00 Arjan Tijms [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5035886i=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=nodenode=5035886i=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=nodenode=5034072i=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

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

2015-06-10 Thread Arjan Tijms

Hi,

On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] 
ml-node+s10n5035887...@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=nodenode=5035887i=0
 For additional commands, e-mail: [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=5035887i=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_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
 .
 NAML
 http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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

2015-06-10 Thread David Blevins

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-05-20 Thread Arjan Tijms

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+s10n5034096...@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=nodenode=5034096i=0
For additional commands, e-mail: [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5034096i=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_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
.
NAML
http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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

2015-05-04 Thread Fjodor Vershinin

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 fjo...@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 arjan.ti...@gmail.com:

Hi,

On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
ml-node+s10n502964...@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.

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

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

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

2015-05-04 Thread Arjan Tijms

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+s10n503407...@n6.nabble.com wrote:

2015-03-04 11:09 GMT+02:00 Fjodor Vershinin [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5034072i=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=nodenode=5034072i=1:

Hi,

On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
[hidden email] http:///user/SendEmail.jtp?type=nodenode=5034072i=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.

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

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

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:

--
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_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
.
NAML

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

2015-05-04 Thread Mark Thomas

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-03-04 Thread Fjodor Vershinin

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 arjan.ti...@gmail.com:

Hi,

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

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

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:

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

2015-02-10 Thread Fjodor Vershinin

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-02-10 Thread Arjan Tijms

Hi,

On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat] 
ml-node+s10n5029627...@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_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
 .
 NAML
 http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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.

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

2015-02-10 Thread Mark Thomas

On 10/02/2015 18:42, Arjan Tijms wrote:
Hi,

On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat]
ml-node+s10n5029627...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

2015-02-10 Thread Arjan Tijms

Hi,

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

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

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

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

2013-08-24 Thread Pilkington, Simon

A couple of months ago my team started looking at integrating JASPIC into
Tomcat. Providing support for JASPIC in Tomcat will reduce the amount of
work required
to provide authentication as well as providing better consistency and
portability across different Tomcat-based projects.

Based on that there has been some interest within the Tomcat community for
this support and the benefits to my team, I am interested in contributing
code changes to Tomcat in this area and I have just filed issue 55479 for
this work. Previously we have done some investigation to utilizing the
support from Geronimo and this seems like the best way to move forward.

I have just started and I am about to go ahead and build the trunk of
Tomcat as a first step. If anyone has any guidance on how to approach this
task or anything in general about providing JASPIC support in Tomcat, it
would be most appreciated.

Cheers,
Simon Pilkington


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

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

2013-08-15 Thread Mark Thomas

On 15/08/2013 00:02, David Blevins wrote:
 
 On Aug 14, 2013, at 2:25 AM, Arjan Tijms arjan.ti...@gmail.com wrote:
 
 markt wrote
 No-one said it would be difficult. TomEE has already done it. We'd just
 need to lift the code. Difficulty really doesn't come into it. If there
 is a demand for it, it will get implemented. If there isn't, it won't.

 Thanks, that's clear!

 Btw, didn't you mean Geronimo there, or really TomEE? Last time I checked
 TomEE didn't have JASPIC implemented yet, but Geronimo of course has.
 
 Right, the code David J wrote some time ago is in Geronimo.

Thanks for the correction.

 If you wanted to roll up your sleeves, we'd be more than happy to see it 
 ported or reimplemented in TomEE.

or Tomcat :)

Mark


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

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

2013-08-15 Thread Arjan Tijms

Hi,

On Thursday, August 15, 2013, markt [via Tomcat] wrote:

 On 15/08/2013 00:02, David Blevins wrote:

  If you wanted to roll up your sleeves, we'd be more than happy to see it
 ported or reimplemented in TomEE.

 or Tomcat :)


Definitely!

I'll also try to contact the guys who said to be working on a Tomcat JASPIC
bridge already. One of them had the intention to release his work as open
source, although he said he had to target Tomcat 6 specifically.

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

2013-08-15 Thread David Blevins


On Aug 15, 2013, at 1:07 AM, Mark Thomas ma...@apache.org wrote:

 If you wanted to roll up your sleeves, we'd be more than happy to see it 
 ported or reimplemented in TomEE.
 
 or Tomcat :)

Even better!

-David


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

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

2013-08-14 Thread Mark Thomas

On 13/08/2013 22:58, Arjan Tijms wrote:
 markt wrote
 we are contacting  standalone and EE web profile Servlet containers 
 [...]
 The has been very little demand from the Apache Tomcat user community to
 support the Java EE web profile.
 
 I guess Ron meant Tomcat with the standalone Servlet container and didn't
 ask for Tomcat to implement the EE web profile ;)

Had you not cut all the context, it would be clear that Ron's question was:
quote
Does the Tomcat community support the inclusion of the Servlet profile
of JSR 196 in the EE web Profile?
/quote
Hence my response. I don't think the Tomcat developers are in a position
to pass judgement on what should or should not be in the web profile as
we have little to no visibility into what users want from the web profile.

Since I wrote that original response, there have been a handful of users
on the users list asking questions about the Tomcat part of TomEE but
nothing to change my view that there has been very little demand for web
profile support from the Tomcat user community.

What I don't have visibility of is the mix of TomEE users between Tomcat
users wanting more and J2EE container users wanting less. From $dayjob,
I see more of the later: folks currently using full J2EE wanting to move
to the web profile or Tomcat.

 markt wrote
 JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off
 because a) it wasn't a mandatory requirement for Servlet containers and
 b) there was very little (no references at all on the users list) for it.
 
 Maybe the last point is because of the classic chicken  egg problem? People
 are not writing portable authentication modules, since they know Tomcat
 doesn't support them. Because of that few of them are being written and thus
 other people do not ask for it.

Maybe. On the other hand, look at the demand from the user community we
saw for WebSocket.

The only folks talking about JSR 196 have been either EG members like
Ron or David, or Tomcat committers mentioning that JSR 196 support was
being considered or might be a possible implementation solution for
something.

Not a single user has asked for JSR 196 support.

 As Ron already demonstrated a bit, the Servlet Profile of JASPIC should be
 relatively easy to support. It's not a complete new feature with a lot of
 code that has to be build into Tomcat (like e.g. supporting CDI would
 require).

No-one said it would be difficult. TomEE has already done it. We'd just
need to lift the code. Difficulty really doesn't come into it. If there
is a demand for it, it will get implemented. If there isn't, it won't.

At the moment the main driver for this, in my view, is to provide an API
for folks that want to do things like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503

JASPIC isn't on the TODO list for 8.0.x but it is still early enough to
add it. Doing this for Tomcat 8 is on my it would be nice to do this if
I can find the time list.

 Instead, it's doing something that Tomcat already does, but (more or less)
 layering some standardized interfaces on top of that. In fact Tomcat's
 JAASRealm
 (http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#JAASRealm) is not
 that far away from a JASPIC implementation.
 
 
 markt wrote
 You'd obviously get a very different reaction if the Servlet spec was
 going to
 require JSR 196 support.
 
 Just out of curiosity, but what would you think the reaction might be if
 that was going to happen?

If the Servlet specification required JSR 196 support then it would get
implemented.

Mark


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

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

2013-08-14 Thread Arjan Tijms

Hi,

markt wrote
Had you not cut all the context, it would be clear that Ron's question
was:
Does the Tomcat community support the inclusion of the Servlet profile
of JSR 196 in the EE web Profile?
Hence my response. I don't think the Tomcat developers are in a position
to pass judgement on what should or should not be in the web profile as
we have little to no visibility into what users want from the web profile.

I see, thanks for the clarification, it's clear to me now.

markt wrote
The only folks talking about JSR 196 have been either EG members like
Ron or David, or Tomcat committers mentioning that JSR 196 support was
being considered or might be a possible implementation solution for
something.

Not a single user has asked for JSR 196 support.

Well, I'm a user asking for it ;)

Personally I know of 2 users who were busy trying to implement a kind of
bridge between JASPIC and Tomcat so that they could use their company's
in-house developed SAM with Tomcat. I don't know why they didn't approach
the Tomcat mailing list or created an issue.

I address JASPIC on my blog, and from the traffic I can see there's some
demand for JASPIC indeed. People do search for things like portable login
module, universal realm Java EE, jaspic, jaspic api etc. Granted,
it's not a very large amount of traffic (currently sits at ~1% of the JSF
traffic, which is a topic I also cover), but it's still there.

As opposed to WebSocket; I think WebSocket addresses a need for which there
wasn't a real solution yet. It's a new feature that got a lot of attention.
JASPIC doesn't really add any new feature, it just standardizes existing
things. People are obviously already building authentication modules, but
seem to have grudgingly accepted that those things are just container
specific.

For some reason JASPIC hasn't been given that much attention. From a user's
point it was almost silently added to the spec. Even the well known Java EE
tutorial from Oracle doesn't mention it. On StackOverflow I mentioned the
existence of JASPIC a couple of times in relevant questions, and even very
experienced Java programmers (judging by their SO rep) were genuinely
surprised that this existed and seemed to be very enthusiastic about the
idea of portable authentication modules. A recent example:
http://stackoverflow.com/questions/5030924/user-group-implementation-compatible-with-jaas/15873533#comment26696282_15873533

markt wrote
No-one said it would be difficult. TomEE has already done it. We'd just
need to lift the code. Difficulty really doesn't come into it. If there
is a demand for it, it will get implemented. If there isn't, it won't.

Thanks, that's clear!

Btw, didn't you mean Geronimo there, or really TomEE? Last time I checked
TomEE didn't have JASPIC implemented yet, but Geronimo of course has.

markt wrote
At the moment the main driver for this, in my view, is to provide an API
for folks that want to do things like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503

Yes, I see. That's a very good example.

Thanks a lot for your detailed response.

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-tp4993387p5003179.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

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

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

2013-08-14 Thread David Blevins


On Aug 14, 2013, at 2:25 AM, Arjan Tijms arjan.ti...@gmail.com wrote:

 markt wrote
 No-one said it would be difficult. TomEE has already done it. We'd just
 need to lift the code. Difficulty really doesn't come into it. If there
 is a demand for it, it will get implemented. If there isn't, it won't.
 
 Thanks, that's clear!
 
 Btw, didn't you mean Geronimo there, or really TomEE? Last time I checked
 TomEE didn't have JASPIC implemented yet, but Geronimo of course has.

Right, the code David J wrote some time ago is in Geronimo.  If you wanted to 
roll up your sleeves, we'd be more than happy to see it ported or reimplemented 
in TomEE.

It's a Full Profile requirement and there has been user-demand for seeing 
TomEE+ be full profile compliant.  Something we'd never have done in EE 6 with 
JAX-RPC and other horrific legacy, but much of that is dropped in EE 7 Full 
Profile.


-David


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

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

2013-08-13 Thread Arjan Tijms

markt wrote
we are contacting standalone and EE web profile Servlet containers
[...]
The has been very little demand from the Apache Tomcat user community to
support the Java EE web profile.

I guess Ron meant Tomcat with the standalone Servlet container and didn't
ask for Tomcat to implement the EE web profile ;)

markt wrote
JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off
because a) it wasn't a mandatory requirement for Servlet containers and
b) there was very little (no references at all on the users list) for it.

Maybe the last point is because of the classic chicken egg problem? People
are not writing portable authentication modules, since they know Tomcat
doesn't support them. Because of that few of them are being written and thus
other people do not ask for it.

As Ron already demonstrated a bit, the Servlet Profile of JASPIC should be
relatively easy to support. It's not a complete new feature with a lot of
code that has to be build into Tomcat (like e.g. supporting CDI would
require).

Instead, it's doing something that Tomcat already does, but (more or less)
layering some standardized interfaces on top of that. In fact Tomcat's
JAASRealm
(http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#JAASRealm) is not
that far away from a JASPIC implementation.

markt wrote
You'd obviously get a very different reaction if the Servlet spec was
going to
require JSR 196 support.

Just out of curiosity, but what would you think the reaction might be if
that was going to happen?

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-tp4993387p5003167.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

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

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

2013-02-06 Thread Ron Monzillo


On 2/3/13 5:02 AM, Mark Thomas wrote:

On 30/01/2013 23:57, Ron Monzillo wrote:

Tomcat Experts and Users,

The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in
support of the portable integration
of new and/or custom authentication mechanisms in compatible Servlet
containers.

The Profile is a required component of all Full Platform EE Web
Containers, and we are receiving requests
for the profile to become a required component of the EE web profile. To
that end, we are contacting
standalone and EE web profile Servlet containers to determine if there
is interest in adopting the profile.

For those unfamiliar with JASPIC, the SPI is a general purpose facility
that applies the concepts of pluggable
authentication as defined by PAM and JAAS to the realm of message
authentication. The Servlet profile applies
the SPI to the realm of HttpServletRequest message authentication in the
context of servlet security constraint
processing. The SPI was defined to support complex challenge response
authentication protocols, and has
been shown to be an effective means to integrate portable
implementations of new internet authentication
mechanisms (e.g. Facebook Connect, and SAML WEB SSO) in compatible
Servlet containers.

Does the Tomcat community support the inclusion of the Servlet profile
of JSR 196 in the EE web Profile?

Apache Tomcat does not currently support the Java EE web profile. Tomcat
currently supports only the Servlet, JSP and EL specifications and will
be adding WebSocket to that list for Tomcat 8.

The has been very little demand from the Apache Tomcat user community to
support the Java EE web profile. There have been just two threads on the
users list that mention the web profile. There have been slightly more
on the dev list.

JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off
because a) it wasn't a mandatory requirement for Servlet containers and
b) there was very little (no references at all on the users list) for it.

I think it would be safe to say that the Apache Tomcat community has no
opinion on the Java EE web profile requiring JSR 196 support. You'd
obviously get a very different reaction if the Servlet spec was going to
require JSR 196 support.

Apache TomEE does support the Java EE web profile. If you haven't
already approached that community for their views, I recommend that you
do so.

Mark,

I have posted the question to the TomEE and Caucho/Resin user's lists.

It would also help to know what the level of interest is from Tomcat 
users and developers.


I anticipate that there are Tomcat users and developers who are committed
to other approaches, but I'd like to make sure the use of JASPIC has been
presented for consideration by the Tomcat community.

I would also like to know if anyone has already done or is interested in 
doing

the work to integrate the JASPIC  profile in the Tomcat code base.

kind regards,

Ron



Kind regards,

Mark


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




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

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

2013-02-06 Thread Mark Thomas

On 06/02/2013 15:45, Ron Monzillo wrote:
 I have posted the question to the TomEE and Caucho/Resin user's lists.
 
 It would also help to know what the level of interest is from Tomcat
 users and developers.

For users@, yours is the first post ever to mention JASPIC. We'll see
what reaction your post gets.

For dev@, it is safe to say it is an itch no-one has wanted to scratch
so far because it hasn't been implemented. User demand could change that
but so far there hasn't been any.

 I anticipate that there are Tomcat users and developers who are committed
 to other approaches, but I'd like to make sure the use of JASPIC has been
 presented for consideration by the Tomcat community.

It has been on our radar for well over 3 years. As I keep saying, so far
no-one seems to be that interested in either using it or implementing it.

 I would also like to know if anyone has already done or is interested in
 doing
 the work to integrate the JASPIC  profile in the Tomcat code base.

I believe the Geronimo folks have had this implemented for a number of
years. If JASPIC support was going to be added to Tomcat, that is
probably where we'd start.

Mark


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

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

2013-02-06 Thread David Jencks

Umm, a few years ago I was quite interested in implementing it for tomcat, but 
couldn't raise any support over here.  I still think the geronimo-tomcat-jaspic 
integration could be adapted to tomcat standalone pretty easily, although I 
don't think I'll have time to work on it.

thanks
david jencks

On Feb 6, 2013, at 10:29 AM, Mark Thomas ma...@apache.org wrote:

 On 06/02/2013 15:45, Ron Monzillo wrote:
 I have posted the question to the TomEE and Caucho/Resin user's lists.
 
 It would also help to know what the level of interest is from Tomcat
 users and developers.
 
 For users@, yours is the first post ever to mention JASPIC. We'll see
 what reaction your post gets.
 
 For dev@, it is safe to say it is an itch no-one has wanted to scratch
 so far because it hasn't been implemented. User demand could change that
 but so far there hasn't been any.
 
 I anticipate that there are Tomcat users and developers who are committed
 to other approaches, but I'd like to make sure the use of JASPIC has been
 presented for consideration by the Tomcat community.
 
 It has been on our radar for well over 3 years. As I keep saying, so far
 no-one seems to be that interested in either using it or implementing it.
 
 I would also like to know if anyone has already done or is interested in
 doing
 the work to integrate the JASPIC  profile in the Tomcat code base.
 
 I believe the Geronimo folks have had this implemented for a number of
 years. If JASPIC support was going to be added to Tomcat, that is
 probably where we'd start.
 
 Mark
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


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

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

2013-02-05 Thread jean-frederic clere


On 01/31/2013 12:57 AM, Ron Monzillo wrote:

Tomcat Experts,

The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in
support of the portable integration
of new and/or custom authentication mechanisms in compatible Servlet
containers.


You probably should ask that to the TomEE user list.

Cheers

Jean-Frederic

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

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

2013-02-03 Thread Mark Thomas

On 30/01/2013 23:57, Ron Monzillo wrote:
 Tomcat Experts,
 
 The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in
 support of the portable integration
 of new and/or custom authentication mechanisms in compatible Servlet
 containers.
 
 The Profile is a required component of all Full Platform EE Web
 Containers, and we are receiving requests
 for the profile to become a required component of the EE web profile. To
 that end, we are contacting
 standalone and EE web profile Servlet containers to determine if there
 is interest in adopting the profile.
 
 For those unfamiliar with JASPIC, the SPI is a general purpose facility
 that applies the concepts of pluggable
 authentication as defined by PAM and JAAS to the realm of message
 authentication. The Servlet profile applies
 the SPI to the realm of HttpServletRequest message authentication in the
 context of servlet security constraint
 processing. The SPI was defined to support complex challenge response
 authentication protocols, and has
 been shown to be an effective means to integrate portable
 implementations of new internet authentication
 mechanisms (e.g. Facebook Connect, and SAML WEB SSO) in compatible
 Servlet containers.
 
 Does the Tomcat community support the inclusion of the Servlet profile
 of JSR 196 in the EE web Profile?

Apache Tomcat does not currently support the Java EE web profile. Tomcat
currently supports only the Servlet, JSP and EL specifications and will
be adding WebSocket to that list for Tomcat 8.

The has been very little demand from the Apache Tomcat user community to
support the Java EE web profile. There have been just two threads on the
users list that mention the web profile. There have been slightly more
on the dev list.

JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off
because a) it wasn't a mandatory requirement for Servlet containers and
b) there was very little (no references at all on the users list) for it.

I think it would be safe to say that the Apache Tomcat community has no
opinion on the Java EE web profile requiring JSR 196 support. You'd
obviously get a very different reaction if the Servlet spec was going to
require JSR 196 support.

Apache TomEE does support the Java EE web profile. If you haven't
already approached that community for their views, I recommend that you
do so.

Kind regards,

Mark


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

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

2013-01-30 Thread Ron Monzillo


Tomcat Experts,

The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in 
support of the portable integration
of new and/or custom authentication mechanisms in compatible Servlet 
containers.


The Profile is a required component of all Full Platform EE Web 
Containers, and we are receiving requests
for the profile to become a required component of the EE web profile. To 
that end, we are contacting
standalone and EE web profile Servlet containers to determine if there 
is interest in adopting the profile.


For those unfamiliar with JASPIC, the SPI is a general purpose facility 
that applies the concepts of pluggable
authentication as defined by PAM and JAAS to the realm of message 
authentication. The Servlet profile applies
the SPI to the realm of HttpServletRequest message authentication in the 
context of servlet security constraint
processing. The SPI was defined to support complex challenge response 
authentication protocols, and has
been shown to be an effective means to integrate portable 
implementations of new internet authentication
mechanisms (e.g. Facebook Connect, and SAML WEB SSO) in compatible 
Servlet containers.


Does the Tomcat community support the inclusion of the Servlet profile 
of JSR 196 in the EE web Profile?


thanks,

Ron Monzillo

--
More details:

The requirements of the profile are spelled out in chapter 3 of the 
JASPIC specification:


http://download.oracle.com/otndocs/jcp/jaspic-1.0-mrel-eval-oth-JSpec/

and use of the SPI is described in high level terms in the javadoc: 
which can be accessed at:


http://docs.oracle.com/javaee/6/api/javax/security/auth/message/config/package-frame.html 



Support for the profile by a servlet container mostly amounts to making 
a few calls to the spi in the
context of the processing of servlet requests. The pattern is basically 
as follows:


// determine if a pluggable auth module is configured for the current 
application
AuthConfigProvider provider = 
AuthConfigFactory.getFactory().getConfigProvider(HttpServlet,appID,listener);


if (provider != null) {
   /if yes, get the server side configuration provider that applies to 
the application


ServerAuthConfig config = 
provider.getServerAuthConfig(HttpServlet,appID,cbh);


// for each request to the application
// get the configuration of authentication modules that applies to 
the request


messageInfo.setRequestMessage(httpServletRequest);
messageInfo.setResponseMessage(httpServletResponse);
String authContextID = config.getAuthContextID(messageInfo);
ServerAuthContext context = 
config.getAuthContext(authContextID,serviceSubject,properties);


// invoke validateRequest on the module configuration; which will 
invoke the configured auth modules


AuthStatus status = 
context.validateRequest(messageInfo,clientSubject,serviceSubject);


if (status == AuthStatus.SUCCESS) {
// Use the proprietary interfaces of the container to set the 
userPrincipal on the request
// proceed to authorize and invoke the servlet request as 
appropriate

} else {
// extract the response from messageInfo and return (it may be 
a challenge or an error message,

// and will have been established by the auth module
}
} else {
   // do what the container would do in the absense of jsr 196
}


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

50 matches

Mail list logo