You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2008/05/28 23:19:32 UTC
[PROPOSAL] Incubate JSecurity Project
Relevant information can be found in:
http://wiki.apache.org/incubator/JSecurityProposal
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Jeremy Haile <jh...@fastmail.fm>.
> I like this idea! We have an application that has a Swing client and
> we talk to the server via Spring remoting. This shared session idea
> sounds intriguing. I might have to look into switching to JSecurity!
> :)
If you're interested in the Swing-web session interaction check out
our Spring sample application. (in the codebase it's under samples/
spring). It deploys a web application from which you can launch a
webstart Swring app. You can then update a value on the webpage and
refresh it in the Swing app, or visa-versa. It shows off the
simplicity of using JSecurity sessions across these two different
environments.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
If you're curious, the two classes end-users use the most are the
Subject (http://www.jsecurity.org/api/org/jsecurity/subject/Subject.html),
and the Session
(http://www.jsecurity.org/api/org/jsecurity/session/Session.html) -
acquired via subject.getSession();
Cheers,
Les
On Fri, May 30, 2008 at 9:55 AM, Les Hazlewood <le...@hazlewood.com> wrote:
> The other thing about JSecurity's enterprise session support is that
> it in many cases serves as a native basic Single Sign-On solution.
> For example, the most common scenario that typically occurs is the
> following (there are several current production environments that work
> like this):
>
> A session is created on some server (HTTP container, no HTTP, it
> doesn't matter - our Session API is the same for all environments).
> I'll call this Application A. The user authenticates during this
> session.
>
> That sessionId is securely transmitted to another server or desktop
> application, I'll call any of these environments Application B.
> Application B would use its own JSecurity infrastructure, but would
> use this sessionId to obtain the associated Subject (aka User) and
> Session information from Application A (remoting call). After this,
> Application B now has a handle to the same session/user information as
> Application B, without a login necessary, thereby achieving SSO.
>
> We have several end-users that do this - Application B is many times a
> Flash/Flex applet or Swing application, using respective RPC
> mechanisms (Flex Data Services, RMI over HTTP) to talk to Application
> A using the sessionId.
>
> We also utilize caching wherever possible in the framework to help
> performance. Because the Session infrastructure utilizes a caching
> layer, it is trivial to get distributed/clustered Sessions for large
> scale applications by just dropping in a clustered caching provider
> (Ehcache on top of Terracotta, GigaSpaces, etc).
>
> As far as simplicity, the JSecurity dev team has worked extremely hard
> to make the API as simple as possible. I have agonized for days
> sometimes on deciding the appropriate name for a class. Things to me
> must be as intuitive and self-documenting as possible, with a clean OO
> structure.
>
> And finally because most of the dev team likes to use Spring, we have
> proper Spring integration (using Spring APIs) to enable JSecurity
> cleanly there as well. Its just the Spring support is optional.
> JSecurity aims to work in any environment, container or not.
>
> Best regards,
>
> Les
>
> On Fri, May 30, 2008 at 9:00 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>
>>> Another differentiator is that JSecurity provides a session framework
>>> that is not limited to being shared across just web-based applications.
>>> We have users that share sessions across multiple environments, such as
>>> Swing apps talking to a server over Spring remoting or RMI, applets, and
>>> web applications - so they can all share common session information in a
>>> heterogeneous environment.
>>>
>>
>> I like this idea! We have an application that has a Swing client and
>> we talk to the server via Spring remoting. This shared session idea
>> sounds intriguing. I might have to look into switching to JSecurity!
>> :)
>>
>>> This simplicity and power is unmatched in any existing security
>>> framework out-of-the-box.
>>>
>>> Finally, JSecurity strives for simplicity in all areas. To this end, it
>>> explicitly supports common security mechanisms used in most applications
>>> such as roles and permissions. This makes code more readable, limits
>>> the amount of custom coding required, and makes security definitions
>>> very concise and readable. Despite our goals of simplicity we also aim
>>> for flexibility - so out of the box the framework should be extremely
>>> easy to get up and running, requiring minimal configuration and custom
>>> code. But for users who have much more advanced needs, JSecurity
>>> provides the pluggability and extensibility to be used for almost any
>>> security application.
>>>
>>
>> The simplicity is definitely needed. Spring Security is confusing at
>> times. They've tried to clean things up a bit in the latest
>> version(s), but it's still tough to wrap your head around. I usually
>> just copy/paste something that I know works. :)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
The other thing about JSecurity's enterprise session support is that
it in many cases serves as a native basic Single Sign-On solution.
For example, the most common scenario that typically occurs is the
following (there are several current production environments that work
like this):
A session is created on some server (HTTP container, no HTTP, it
doesn't matter - our Session API is the same for all environments).
I'll call this Application A. The user authenticates during this
session.
That sessionId is securely transmitted to another server or desktop
application, I'll call any of these environments Application B.
Application B would use its own JSecurity infrastructure, but would
use this sessionId to obtain the associated Subject (aka User) and
Session information from Application A (remoting call). After this,
Application B now has a handle to the same session/user information as
Application B, without a login necessary, thereby achieving SSO.
We have several end-users that do this - Application B is many times a
Flash/Flex applet or Swing application, using respective RPC
mechanisms (Flex Data Services, RMI over HTTP) to talk to Application
A using the sessionId.
We also utilize caching wherever possible in the framework to help
performance. Because the Session infrastructure utilizes a caching
layer, it is trivial to get distributed/clustered Sessions for large
scale applications by just dropping in a clustered caching provider
(Ehcache on top of Terracotta, GigaSpaces, etc).
As far as simplicity, the JSecurity dev team has worked extremely hard
to make the API as simple as possible. I have agonized for days
sometimes on deciding the appropriate name for a class. Things to me
must be as intuitive and self-documenting as possible, with a clean OO
structure.
And finally because most of the dev team likes to use Spring, we have
proper Spring integration (using Spring APIs) to enable JSecurity
cleanly there as well. Its just the Spring support is optional.
JSecurity aims to work in any environment, container or not.
Best regards,
Les
On Fri, May 30, 2008 at 9:00 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>
>> Another differentiator is that JSecurity provides a session framework
>> that is not limited to being shared across just web-based applications.
>> We have users that share sessions across multiple environments, such as
>> Swing apps talking to a server over Spring remoting or RMI, applets, and
>> web applications - so they can all share common session information in a
>> heterogeneous environment.
>>
>
> I like this idea! We have an application that has a Swing client and
> we talk to the server via Spring remoting. This shared session idea
> sounds intriguing. I might have to look into switching to JSecurity!
> :)
>
>> This simplicity and power is unmatched in any existing security
>> framework out-of-the-box.
>>
>> Finally, JSecurity strives for simplicity in all areas. To this end, it
>> explicitly supports common security mechanisms used in most applications
>> such as roles and permissions. This makes code more readable, limits
>> the amount of custom coding required, and makes security definitions
>> very concise and readable. Despite our goals of simplicity we also aim
>> for flexibility - so out of the box the framework should be extremely
>> easy to get up and running, requiring minimal configuration and custom
>> code. But for users who have much more advanced needs, JSecurity
>> provides the pluggability and extensibility to be used for almost any
>> security application.
>>
>
> The simplicity is definitely needed. Spring Security is confusing at
> times. They've tried to clean things up a bit in the latest
> version(s), but it's still tough to wrap your head around. I usually
> just copy/paste something that I know works. :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
> Another differentiator is that JSecurity provides a session framework
> that is not limited to being shared across just web-based applications.
> We have users that share sessions across multiple environments, such as
> Swing apps talking to a server over Spring remoting or RMI, applets, and
> web applications - so they can all share common session information in a
> heterogeneous environment.
>
I like this idea! We have an application that has a Swing client and
we talk to the server via Spring remoting. This shared session idea
sounds intriguing. I might have to look into switching to JSecurity!
:)
> This simplicity and power is unmatched in any existing security
> framework out-of-the-box.
>
> Finally, JSecurity strives for simplicity in all areas. To this end, it
> explicitly supports common security mechanisms used in most applications
> such as roles and permissions. This makes code more readable, limits
> the amount of custom coding required, and makes security definitions
> very concise and readable. Despite our goals of simplicity we also aim
> for flexibility - so out of the box the framework should be extremely
> easy to get up and running, requiring minimal configuration and custom
> code. But for users who have much more advanced needs, JSecurity
> provides the pluggability and extensibility to be used for almost any
> security application.
>
The simplicity is definitely needed. Spring Security is confusing at
times. They've tried to clean things up a bit in the latest
version(s), but it's still tough to wrap your head around. I usually
just copy/paste something that I know works. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Jeremy Haile <jh...@fastmail.fm>.
The fact that JSecurity is container-agnostic is certainly a
differentiator. JSecurity aims to support security in any environment.
In fact, we have several users that are using JSecurity in non-web
environments, such as pure-service layers or even Swing applications.
JSecurity also aims to greatly reduce the amount of configuration
required to setup security in an application. In many cases, JSecurity
can be configured in web-based environments via a single filter
definition.
Another differentiator is that JSecurity provides a session framework
that is not limited to being shared across just web-based applications.
We have users that share sessions across multiple environments, such as
Swing apps talking to a server over Spring remoting or RMI, applets, and
web applications - so they can all share common session information in a
heterogeneous environment.
JSecurity also provides powerful dynamic, instance-level authorization
control. Essentially JSecurity supports powerful instance-level control
using String-based permissions (or Object-based, depending on
preference/environment). For example, I could simply grant a user a
"sendNewsletter" permission. But if I wanted instance level control, I
might grant them the permission "newsletter:send:123" where 123 is the
ID of the newsletter that they are allowed to send. I could even grant
a user permission to "newsletter:send:*" or "newsletter:send:123,124"
Then when I check to see if the user has the permission for
"newsletter:send:124" JSecurity would grant the authorization.
This simplicity and power is unmatched in any existing security
framework out-of-the-box.
Finally, JSecurity strives for simplicity in all areas. To this end, it
explicitly supports common security mechanisms used in most applications
such as roles and permissions. This makes code more readable, limits
the amount of custom coding required, and makes security definitions
very concise and readable. Despite our goals of simplicity we also aim
for flexibility - so out of the box the framework should be extremely
easy to get up and running, requiring minimal configuration and custom
code. But for users who have much more advanced needs, JSecurity
provides the pluggability and extensibility to be used for almost any
security application.
Please don't hesitate to ask further questions.
Jeremy
On Fri, 30 May 2008 08:04:34 -0400, "James Carman"
<ja...@carmanconsulting.com> said:
> Isn't there something that states that an incubating project needs to
> be novel or provide something that's not already provided by another
> library (with an open-source license)? I have looked at the JSecurity
> proposal only briefly, but it seems to me that most of what it aims to
> provide is already provided by Spring Security (a.k.a. Acegi).
> Although, Spring Security is somewhat bound to the Spring framework
> (they implement InitializingBean and stuff), so that might be what
> JSecurity is trying to provide, a container-agnostic security
> framework.
>
> On Fri, May 30, 2008 at 2:32 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > Hi,
> >
> > On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >> ...http://wiki.apache.org/incubator/JSecurityProposal...
> >
> > Looks good to me, IMHO this is ready for a vote.
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, May 30, 2008 at 11:47 AM, James Carman <ja...@carmanconsulting.com>
wrote
> On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <ak...@apache.org>
> wrote:
>
> > There's no uniqueness requirement AFAIK. Any kind of project can be
> > proposed even if there already exist multiple implementations of a
> similar
> > technology here at the ASF and abroad.
> >
>
> Perhaps the uniqueness/novel restriction is for Apache Commons
> projects. Or, perhaps I just made it up out of thin air! :)
>
Hey, nothing to worry about I thought this for years myself. :)
Alex
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
Hi Craig,
We're definitely happy to have you as a mentor. Thanks for joining in!
Have you joined the developer list? I have at least one question to ask you
thus far, but I don't want to hijack this thread.
Thanks!
Les
On Sun, Jun 1, 2008 at 2:52 PM, Craig L Russell <Cr...@sun.com>
wrote:
> On Jun 1, 2008, at 10:53 AM, Alan D. Cabrera wrote:
>
>>
>> On May 31, 2008, at 7:27 PM, Craig L Russell wrote:
>>
>> I've signed on to mentor this project.
>>>
>>
>> Great!
>>
>> Maybe there is a "fast track" through the incubator, and this is a good
>>> project to try it out. Can JSecurity get graduated in six months?
>>>
>>
>> IIUC, all incubator projects are on the "fast track".
>>
>
> Well, there is a big difference between entry and exit criteria for the
> incubator. Many projects entering incubation need to resolve IP issues,
> build a community, and learn how to work in open source. So, no, I don't
> think all projects are on the fast track.
>
> I personally like to see one release under incubation to see the podling
>> in action.
>>
>
> And most incubator folks agree.
>
> It's always interesting to see what happens when people outside the
>> original clique start contributing to the project.
>>
>
> Yes, community building is a big part of incubation.
>
> Craig
>
>>
>> Regards,
>> Alan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Alex,
I think the proposal is a good one and has good prospects for success.
No quarrel with anything you've said.
Craig
On Jun 1, 2008, at 12:29 PM, Alex Karasulu wrote:
> On Sun, Jun 1, 2008 at 2:52 PM, Craig L Russell
> <Cr...@sun.com>
> wrote:
>
>> On Jun 1, 2008, at 10:53 AM, Alan D. Cabrera wrote:
>>
>>>
>>> On May 31, 2008, at 7:27 PM, Craig L Russell wrote:
>>>
>>> I've signed on to mentor this project.
>>>>
>>>
>>> Great!
>>>
>>> Maybe there is a "fast track" through the incubator, and this is a
>>> good
>>>> project to try it out. Can JSecurity get graduated in six months?
>>>>
>>>
>>> IIUC, all incubator projects are on the "fast track".
>>>
>>
>> Well, there is a big difference between entry and exit criteria for
>> the
>> incubator. Many projects entering incubation need to resolve IP
>> issues,
>> build a community, and learn how to work in open source. So, no, I
>> don't
>> think all projects are on the fast track.
>>
>
> It's all up to the community. They're in charge of their destiny
> and it's
> up to them to achieve what is required for graduation.
>
> Bottom line, the podling must meet the Apache Incubator's criteria.
> If that
> occurs quickly then wonderful, if not, then it may take some more
> time to
> cook. It may never graduate at all if the criteria are not met and
> the
> right community does not gel. Furthermore, the project may decide
> down the
> road that the Apache Way may not be the best way for them. Who
> knows? Even
> with our easiest incubation (Wicket I think) we were hopeful at the
> start
> but you just never know how long this will take.
>
> Healthy stable communities form like a fine wine and rushing
> graduation is
> like rushing the fermentation process. It takes a while to get
> there but
> when we do we've got a gem. Regardless though, let's not impose
> artificial
> time frames on increasing or decreasing the incubation time. Let's
> just get
> on with meeting the criteria for graduation. That's the best that
> we can
> do.
>
>
>>
>>
>> I personally like to see one release under incubation to see the
>> podling
>>> in action.
>>>
>>
>> And most incubator folks agree.
>>
>
> +1
>
> Regards,
> Alex
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Alex Karasulu <ak...@apache.org>.
On Sun, Jun 1, 2008 at 2:52 PM, Craig L Russell <Cr...@sun.com>
wrote:
> On Jun 1, 2008, at 10:53 AM, Alan D. Cabrera wrote:
>
>>
>> On May 31, 2008, at 7:27 PM, Craig L Russell wrote:
>>
>> I've signed on to mentor this project.
>>>
>>
>> Great!
>>
>> Maybe there is a "fast track" through the incubator, and this is a good
>>> project to try it out. Can JSecurity get graduated in six months?
>>>
>>
>> IIUC, all incubator projects are on the "fast track".
>>
>
> Well, there is a big difference between entry and exit criteria for the
> incubator. Many projects entering incubation need to resolve IP issues,
> build a community, and learn how to work in open source. So, no, I don't
> think all projects are on the fast track.
>
It's all up to the community. They're in charge of their destiny and it's
up to them to achieve what is required for graduation.
Bottom line, the podling must meet the Apache Incubator's criteria. If that
occurs quickly then wonderful, if not, then it may take some more time to
cook. It may never graduate at all if the criteria are not met and the
right community does not gel. Furthermore, the project may decide down the
road that the Apache Way may not be the best way for them. Who knows? Even
with our easiest incubation (Wicket I think) we were hopeful at the start
but you just never know how long this will take.
Healthy stable communities form like a fine wine and rushing graduation is
like rushing the fermentation process. It takes a while to get there but
when we do we've got a gem. Regardless though, let's not impose artificial
time frames on increasing or decreasing the incubation time. Let's just get
on with meeting the criteria for graduation. That's the best that we can
do.
>
>
> I personally like to see one release under incubation to see the podling
>> in action.
>>
>
> And most incubator folks agree.
>
+1
Regards,
Alex
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jun 1, 2008, at 10:53 AM, Alan D. Cabrera wrote:
>
> On May 31, 2008, at 7:27 PM, Craig L Russell wrote:
>
>> I've signed on to mentor this project.
>
> Great!
>
>> Maybe there is a "fast track" through the incubator, and this is a
>> good project to try it out. Can JSecurity get graduated in six
>> months?
>
> IIUC, all incubator projects are on the "fast track".
Well, there is a big difference between entry and exit criteria for
the incubator. Many projects entering incubation need to resolve IP
issues, build a community, and learn how to work in open source. So,
no, I don't think all projects are on the fast track.
> I personally like to see one release under incubation to see the
> podling in action.
And most incubator folks agree.
> It's always interesting to see what happens when people outside the
> original clique start contributing to the project.
Yes, community building is a big part of incubation.
Craig
>
> Regards,
> Alan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On May 31, 2008, at 7:27 PM, Craig L Russell wrote:
> I've signed on to mentor this project.
Great!
> Maybe there is a "fast track" through the incubator, and this is a
> good project to try it out. Can JSecurity get graduated in six months?
IIUC, all incubator projects are on the "fast track". I personally
like to see one release under incubation to see the podling in
action. It's always interesting to see what happens when people
outside the original clique start contributing to the project.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, May 31, 2008 at 7:27 PM, Craig L Russell <Cr...@sun.com> wrote:
> IMHO, the decision on build tools belongs to the community.
>
> I've signed on to mentor this project.
>
> Maybe there is a "fast track" through the incubator, and this is a good
> project to try it out. Can JSecurity get graduated in six months?
>
This would probably depends on the podling being able to demonstrate
to IPMC that they are ready and they have met the requirements in [1].
Having said that, I have seen podlings that are very active, lots of
users, but having difficulty to really get the Apache Way.
[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
> Craig
>
> On May 30, 2008, at 9:08 AM, Jeremy Haile wrote:
>
>> Ant+Ivy vs Maven =)
>>
>>
>> On May 30, 2008, at 12:06 PM, James Carman wrote:
>>
>>> On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
>>> <el...@apache.org> wrote:
>>>
>>>> Maven vs Ant vs Buildr ?
>>>
>>> Who uses Ant or Buildr? ;)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Craig L Russell <Cr...@Sun.COM>.
IMHO, the decision on build tools belongs to the community.
I've signed on to mentor this project.
Maybe there is a "fast track" through the incubator, and this is a
good project to try it out. Can JSecurity get graduated in six months?
Craig
On May 30, 2008, at 9:08 AM, Jeremy Haile wrote:
> Ant+Ivy vs Maven =)
>
>
> On May 30, 2008, at 12:06 PM, James Carman wrote:
>
>> On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
>> <el...@apache.org> wrote:
>>
>>> Maven vs Ant vs Buildr ?
>>
>> Who uses Ant or Buildr? ;)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Jeremy Haile <jh...@fastmail.fm>.
Ant+Ivy vs Maven =)
On May 30, 2008, at 12:06 PM, James Carman wrote:
> On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
> <el...@apache.org> wrote:
>
>> Maven vs Ant vs Buildr ?
>
> Who uses Ant or Buildr? ;)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
<el...@apache.org> wrote:
> Maven vs Ant vs Buildr ?
Who uses Ant or Buildr? ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Emmanuel Lecharny <el...@apache.org>.
James Carman wrote:
> On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <ak...@apache.org> wrote:
>
>
>> There's no uniqueness requirement AFAIK. Any kind of project can be
>> proposed even if there already exist multiple implementations of a similar
>> technology here at the ASF and abroad.
>>
>>
>
> Perhaps the uniqueness/novel restriction is for Apache Commons
> projects. Or, perhaps I just made it up out of thin air! :)
>
Maven vs Ant vs Buildr ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <ak...@apache.org> wrote:
> There's no uniqueness requirement AFAIK. Any kind of project can be
> proposed even if there already exist multiple implementations of a similar
> technology here at the ASF and abroad.
>
Perhaps the uniqueness/novel restriction is for Apache Commons
projects. Or, perhaps I just made it up out of thin air! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Emmanuel Lecharny <el...@apache.org>.
Alan D. Cabrera wrote:
>
> On May 30, 2008, at 5:27 AM, Alex Karasulu wrote:
>
>> On Fri, May 30, 2008 at 8:04 AM, James Carman
>> <ja...@carmanconsulting.com>
>> wrote:
>>
>>> Isn't there something that states that an incubating project needs to
>>> be novel or provide something that's not already provided by another
>>> library (with an open-source license)? I have looked at the JSecurity
>>> proposal only briefly, but it seems to me that most of what it aims to
>>> provide is already provided by Spring Security (a.k.a. Acegi).
>>> Although, Spring Security is somewhat bound to the Spring framework
>>> (they implement InitializingBean and stuff), so that might be what
>>> JSecurity is trying to provide, a container-agnostic security
>>> framework.
>>>
>>
>> There's no uniqueness requirement AFAIK. Any kind of project can be
>> proposed even if there already exist multiple implementations of a
>> similar
>> technology here at the ASF and abroad.
>
> Well put. Let a thousand flowers bloom.
This is also what the incubator is good for ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On May 30, 2008, at 5:27 AM, Alex Karasulu wrote:
> On Fri, May 30, 2008 at 8:04 AM, James Carman <james@carmanconsulting.com
> >
> wrote:
>
>> Isn't there something that states that an incubating project needs to
>> be novel or provide something that's not already provided by another
>> library (with an open-source license)? I have looked at the
>> JSecurity
>> proposal only briefly, but it seems to me that most of what it aims
>> to
>> provide is already provided by Spring Security (a.k.a. Acegi).
>> Although, Spring Security is somewhat bound to the Spring framework
>> (they implement InitializingBean and stuff), so that might be what
>> JSecurity is trying to provide, a container-agnostic security
>> framework.
>>
>
> There's no uniqueness requirement AFAIK. Any kind of project can be
> proposed even if there already exist multiple implementations of a
> similar
> technology here at the ASF and abroad.
Well put. Let a thousand flowers bloom.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, May 30, 2008 at 8:04 AM, James Carman <ja...@carmanconsulting.com>
wrote:
> Isn't there something that states that an incubating project needs to
> be novel or provide something that's not already provided by another
> library (with an open-source license)? I have looked at the JSecurity
> proposal only briefly, but it seems to me that most of what it aims to
> provide is already provided by Spring Security (a.k.a. Acegi).
> Although, Spring Security is somewhat bound to the Spring framework
> (they implement InitializingBean and stuff), so that might be what
> JSecurity is trying to provide, a container-agnostic security
> framework.
>
There's no uniqueness requirement AFAIK. Any kind of project can be
proposed even if there already exist multiple implementations of a similar
technology here at the ASF and abroad.
Regards,
Alex
>
> On Fri, May 30, 2008 at 2:32 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > Hi,
> >
> > On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >> ...http://wiki.apache.org/incubator/JSecurityProposal...
> >
> > Looks good to me, IMHO this is ready for a vote.
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [PROPOSAL] Incubate JSecurity Project
Posted by James Carman <ja...@carmanconsulting.com>.
Isn't there something that states that an incubating project needs to
be novel or provide something that's not already provided by another
library (with an open-source license)? I have looked at the JSecurity
proposal only briefly, but it seems to me that most of what it aims to
provide is already provided by Spring Security (a.k.a. Acegi).
Although, Spring Security is somewhat bound to the Spring framework
(they implement InitializingBean and stuff), so that might be what
JSecurity is trying to provide, a container-agnostic security
framework.
On Fri, May 30, 2008 at 2:32 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>
> Looks good to me, IMHO this is ready for a vote.
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Day after day, acres of pixels are needlessly harvested because of the
shear hubris in the decision to name this list "general" and not
"gen". Our planet's oceans just cannot support this unbridled
consumption. Plus there's of all the megawatts expended just to even
render that extra "eral". Not to mention all that post-consumer waste
that needs to be dealt with. I'm sorry but that's not the kind of
legacy I want to leave my children.
I think that it's time that the ASF instantiate a foundation wide
"green" policy and it should start with "jsec".
Regards,
Alan
P.S. TGIF
On Jun 3, 2008, at 11:35 AM, Craig L Russell wrote:
> Hi Alan,
>
> On Jun 3, 2008, at 11:18 AM, Alan D. Cabrera wrote:
>
>> Kinda long, IMO.
>
> If users had to type the alias, I'd agree that it's kinda long. But
> when do you type email aliases any more?
>
> Regards,
>
> Craig
>>
>>
>>
>> Regards,
>> Alan
>>
>> On Jun 2, 2008, at 9:01 AM, Craig L Russell wrote:
>>
>>> One more nit comment on the proposal.
>>>
>>> The mailing lists proposed are prefixed with jsec, but the project
>>> name and mailing lists on codehaus.org are "jsecurity".
>>>
>>> Shouldn't the aliases in Apache be jsecurity-xxx?
>>>
>>> Craig
>>>
>>> On May 30, 2008, at 8:45 AM, Alan D. Cabrera wrote:
>>>
>>>>
>>>> On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <list@toolazydogs.com
>>>>> > wrote:
>>>>>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>>>>>
>>>>> Looks good to me, IMHO this is ready for a vote.
>>>>
>>>> Thanks. I'll let the weekend crowd peruse the proposal and start
>>>> a vote on Monday.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Alan,
On Jun 3, 2008, at 11:18 AM, Alan D. Cabrera wrote:
> Kinda long, IMO.
If users had to type the alias, I'd agree that it's kinda long. But
when do you type email aliases any more?
Regards,
Craig
>
>
>
> Regards,
> Alan
>
> On Jun 2, 2008, at 9:01 AM, Craig L Russell wrote:
>
>> One more nit comment on the proposal.
>>
>> The mailing lists proposed are prefixed with jsec, but the project
>> name and mailing lists on codehaus.org are "jsecurity".
>>
>> Shouldn't the aliases in Apache be jsecurity-xxx?
>>
>> Craig
>>
>> On May 30, 2008, at 8:45 AM, Alan D. Cabrera wrote:
>>
>>>
>>> On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <list@toolazydogs.com
>>>> > wrote:
>>>>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>>>>
>>>> Looks good to me, IMHO this is ready for a vote.
>>>
>>> Thanks. I'll let the weekend crowd peruse the proposal and start
>>> a vote on Monday.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Kinda long, IMO.
Regards,
Alan
On Jun 2, 2008, at 9:01 AM, Craig L Russell wrote:
> One more nit comment on the proposal.
>
> The mailing lists proposed are prefixed with jsec, but the project
> name and mailing lists on codehaus.org are "jsecurity".
>
> Shouldn't the aliases in Apache be jsecurity-xxx?
>
> Craig
>
> On May 30, 2008, at 8:45 AM, Alan D. Cabrera wrote:
>
>>
>> On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
>>
>>> Hi,
>>>
>>> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <list@toolazydogs.com
>>> > wrote:
>>>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>>>
>>> Looks good to me, IMHO this is ready for a vote.
>>
>> Thanks. I'll let the weekend crowd peruse the proposal and start a
>> vote on Monday.
>>
>>
>> Regards,
>> Alan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Jeremy Haile <jh...@fastmail.fm>.
I usually like shorter "code names" for JIRA b/c it is easier to
type. For example, when looking up a specific issue number using
search or including in SVN comments during commit.
+1 for JSEC in JIRA
(although jsecurity makes sense for mailing lists)
On Jun 2, 2008, at 12:29 PM, Les Hazlewood wrote:
> I prefer JSEC for Jira just because that is what we use now. It has
> grown
> on me ;)
>
> If any sub projects come , then JSECSUBA, JSECSUBB, JSECSUBC, etc
> feel a
> little more digestible (at least in length) than JSECURITY-SUBA, etc.
>
> Just my .02
>
> On Mon, Jun 2, 2008 at 12:16 PM, Emmanuel Lecharny <elecharny@apache.org
> >
> wrote:
>
>> Les Hazlewood wrote:
>>
>>> Sure, that sounds good to me. I'll update the proposal...
>>>
>>>
>>
>> Then maybe JSECURITY for Jira too might be good. Not sure...
>> Depends if we
>> will have many sub-projects, which might be a good idea, regarding
>> the
>> various funtionalities.
>>
>> wdyt ?
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Emmanuel Lecharny <el...@apache.org>.
Les Hazlewood wrote:
> I prefer JSEC for Jira just because that is what we use now. It has grown
> on me ;)
>
> If any sub projects come , then JSECSUBA, JSECSUBB, JSECSUBC, etc feel a
> little more digestible (at least in length) than JSECURITY-SUBA, etc.
>
Yep. We have the same on Directory : DIRSERVER, DIRTSEC, etc...
Mails are somehow a different beast as you won't have more than a few
ML, namely users, commits, dev, private, while you may have a dozen of
JIRA names.
Forget about my proposal.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Alex Karasulu <ak...@apache.org>.
Makes sense to me Les.
Alex
On Mon, Jun 2, 2008 at 12:29 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> I prefer JSEC for Jira just because that is what we use now. It has grown
> on me ;)
>
> If any sub projects come , then JSECSUBA, JSECSUBB, JSECSUBC, etc feel a
> little more digestible (at least in length) than JSECURITY-SUBA, etc.
>
> Just my .02
>
> On Mon, Jun 2, 2008 at 12:16 PM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
> > Les Hazlewood wrote:
> >
> >> Sure, that sounds good to me. I'll update the proposal...
> >>
> >>
> >
> > Then maybe JSECURITY for Jira too might be good. Not sure... Depends if
> we
> > will have many sub-projects, which might be a good idea, regarding the
> > various funtionalities.
> >
> > wdyt ?
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
I prefer JSEC for Jira just because that is what we use now. It has grown
on me ;)
If any sub projects come , then JSECSUBA, JSECSUBB, JSECSUBC, etc feel a
little more digestible (at least in length) than JSECURITY-SUBA, etc.
Just my .02
On Mon, Jun 2, 2008 at 12:16 PM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Les Hazlewood wrote:
>
>> Sure, that sounds good to me. I'll update the proposal...
>>
>>
>
> Then maybe JSECURITY for Jira too might be good. Not sure... Depends if we
> will have many sub-projects, which might be a good idea, regarding the
> various funtionalities.
>
> wdyt ?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Emmanuel Lecharny <el...@apache.org>.
Les Hazlewood wrote:
> Sure, that sounds good to me. I'll update the proposal...
>
Then maybe JSECURITY for Jira too might be good. Not sure... Depends if
we will have many sub-projects, which might be a good idea, regarding
the various funtionalities.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
Sure, that sounds good to me. I'll update the proposal...
On Mon, Jun 2, 2008 at 12:01 PM, Craig L Russell <Cr...@sun.com>
wrote:
> One more nit comment on the proposal.
>
> The mailing lists proposed are prefixed with jsec, but the project name and
> mailing lists on codehaus.org are "jsecurity".
>
> Shouldn't the aliases in Apache be jsecurity-xxx?
>
> Craig
>
>
> On May 30, 2008, at 8:45 AM, Alan D. Cabrera wrote:
>
>
>> On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
>>
>> Hi,
>>>
>>> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>
>>>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>>>>
>>>
>>> Looks good to me, IMHO this is ready for a vote.
>>>
>>
>> Thanks. I'll let the weekend crowd peruse the proposal and start a vote
>> on Monday.
>>
>>
>> Regards,
>> Alan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Craig L Russell <Cr...@Sun.COM>.
One more nit comment on the proposal.
The mailing lists proposed are prefixed with jsec, but the project
name and mailing lists on codehaus.org are "jsecurity".
Shouldn't the aliases in Apache be jsecurity-xxx?
Craig
On May 30, 2008, at 8:45 AM, Alan D. Cabrera wrote:
>
> On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
>
>> Hi,
>>
>> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <list@toolazydogs.com
>> > wrote:
>>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>>
>> Looks good to me, IMHO this is ready for a vote.
>
> Thanks. I'll let the weekend crowd peruse the proposal and start a
> vote on Monday.
>
>
> Regards,
> Alan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <list@toolazydogs.com
> > wrote:
>> ...http://wiki.apache.org/incubator/JSecurityProposal...
>
> Looks good to me, IMHO this is ready for a vote.
Thanks. I'll let the weekend crowd peruse the proposal and start a
vote on Monday.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> ...http://wiki.apache.org/incubator/JSecurityProposal...
Looks good to me, IMHO this is ready for a vote.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Alex Karasulu <ak...@apache.org>.
On Sun, Jun 8, 2008 at 12:16 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> The reason it is not in place now and hasn't been in 3 years is that
> because the vast majority of our community - application and framework
> developers - could care less about JAAS - it is a cumbersome,
> difficult to understand, quirky mechanism.
>
+1 to that. Java 2 Security in general is a complete mess. It's an utterly
convoluted mosaic, parts of which have been pieced together as its flaws
were slowly discovered over time. I've got far too many bones to pick with
JAAS to inject into this thread, but top on my list is the fact that it's a
complete misnomer: it barely accounts for any kind of AuthZ. At best, it's
Java's PAM framework.
>
> I've given presentations on JSecurity and had many discussions in
> private, and I always ask my audience: "How many people have heard of
> JAAS?" Maybe 40-50% of the listeners affirm they have. Then I ask,
> "how many of you have used the JAAS API or its constructs (permissions
> files, etc)?". That number has been consistently around 1-2%.
>
Question is, what portion of that 1-2% are involved in writing containers?
:)
>
> In fact, JAAS was _the_ primary driving factor in what eventually
> became JSecurity: I had to execute a number of security operations
> for an application, and the only thing out there was JAAS. I found
> myself drowning in their mish-mash of incomprehensible APIs and
> obscure VM-level security constructs (which I didn't care about - I
> wanted application-level security).
I've had a similar situation and have for some time been searching for a
coherent API to tie together both system, and application space security
with some elegance. This has lead to some of our work on ApacheDS and
Triplesec [0] at Apache Directory. Although we might not have the whole
picture yet, we do see some synergy between protocols like Kerberos, LDAP
and general application security. After all, at some point, applications
are dropped into environments and thats where we see most frameworks loosing
some of their elegance. As I said, I can't say we have the full picture
yet, but hopefully with JSecurity in the family we can round out that
picture better.
SNIP
>
> Finally, although not necessarily our initial intentions, I think it
> would be amazing if JSecurity could be a model for a new JSR that
> could supplement or replace what JAAS is today. I don't know if that
> will ever happen, but if we as an ASF community desire it, then I
> think it would be a great idea for further discussion.
>
That would be wonderful but we don't need the JCP to bless a coherent API.
The user community will do that for us. "Build it [well] and they will
come", and eventually it will become the status quo. The JSR thingy is just
sprinkles on the frosting.
I've been on he hunt for a solid RBAC API that fits well with Java 2
security, while being simple, and easy to use for application developers for
some time now. At the same time I've wanted it to have enough granularity
to be able to expose policies expressed in SAML/XACML. I've tried designing
one several times, and found several shortcomings after looking at
integrating it into the big picture. Hopefully something worth while will
emerge soon. That's my technical hope for JSecurity, which eventually I'd
like to roll into Apache Triplesec. My hopes for this podling and its
community are independent from my technical aspirations and so the community
can still succeed where the technical aims may fail. Hopefully though we
can kill many birds with one stone.
Alex
P.S. this my AuthZ bible [1].
-------
[0] - http://directory.apache.org/triplesec
[1] -
http://www.amazon.com/Role-Based-Access-Control-Second-Ferraiolo/dp/1596931132
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> In fact, JAAS was _the_ primary driving factor in what eventually
> became JSecurity: I had to execute a number of security operations
> for an application, and the only thing out there was JAAS. I found
> myself drowning in their mish-mash of incomprehensible APIs and
> obscure VM-level security constructs (which I didn't care about - I
> wanted application-level security). So, I wrote an alternative that
> only worked in that current application (covered in the Project
> History on our About page: http://www.jsecurity.org/about), and
> changed it over time to be flexible for any application.
JSPWiki uses JAAS.
It's consistently been the single biggest source of user problems for
us. Or was, until we rewrote big portions of the API to get rid of
JAR signing and the "one policy per VM" rules (and a bunch of other
small annoyances which kept us tearing our hairs out and made
everybody pester us). JAAS works for us now, because there's almost
none of it left anymore. We still interface with it, but it took a
long time to make it user-friendly and relatively zero-config.
I personally applaud any attempt to actually make an usable, generic
and flexible security system, and it would be wonderful if Apache
could offer that.
/Janne
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Incubate JSecurity Project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Les Hazlewood wrote:
> I've given presentations on JSecurity and had many discussions in
> private, and I always ask my audience: "How many people have heard
> of JAAS?" Maybe 40-50% of the listeners affirm they have. Then I
> ask, "how many of you have used the JAAS API or its constructs
> (permissions files, etc)?". That number has been consistently
> around 1-2%.
Right. But that is probably because most of the other 98%-99% of JEE developers rely on container-managed access, and don't write any security code. If anything, they might make a role-check in UI code to see what navigation options to offer. The percentage of JEE developers who need more than container-managed, role-based, authorization is relatively low, although for those who need it, it is essential.
Container-managed security fails at the instance level, e.g., the container can restrict access to the ClientAccount bean methods to the Customer role, but does not enforce WHICH customer login can access WHICH bean instance. What is JSecurity's approach, and what would it look like for the lookup (JNDI) and injection (annotation) models?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
Full JAAS integration is desired for the 1.0 final release to support
those who actually implement containers. JSecurity is usable in all
containers today, both web and non-web today, just not via JAAS yet.
The reason it is not in place now and hasn't been in 3 years is that
because the vast majority of our community - application and framework
developers - could care less about JAAS - it is a cumbersome,
difficult to understand, quirky mechanism.
I've given presentations on JSecurity and had many discussions in
private, and I always ask my audience: "How many people have heard of
JAAS?" Maybe 40-50% of the listeners affirm they have. Then I ask,
"how many of you have used the JAAS API or its constructs (permissions
files, etc)?". That number has been consistently around 1-2%.
In fact, JAAS was _the_ primary driving factor in what eventually
became JSecurity: I had to execute a number of security operations
for an application, and the only thing out there was JAAS. I found
myself drowning in their mish-mash of incomprehensible APIs and
obscure VM-level security constructs (which I didn't care about - I
wanted application-level security). So, I wrote an alternative that
only worked in that current application (covered in the Project
History on our About page: http://www.jsecurity.org/about), and
changed it over time to be flexible for any application.
The end result is a framework that is far more desirable for the huge
majority of people that write applications. In fact, in the history
of the project, I've only come across 2 or 3 indications that an
effort for full JAAS support is desired - two over a year ago and now
in this thread. So, you can see why we haven't spent much time in
actually accomplishing this.
But, all of this being said, we have _always_ expected to integrate
very nicely with JAAS in either way: JAAS sits on top of JSecurity or
JSecurity on top of JAAS, using whatever JAAS integration mechanisms
that exist. We're hoping with our adoption in the ASF community, that
people will join the project to assist in this effort specifically.
The JSecurity API has been designed such that JAAS integration,
whenever needed, would be a simple task. That has always been in the
back of our minds, 'just in case'.
Finally, although not necessarily our initial intentions, I think it
would be amazing if JSecurity could be a model for a new JSR that
could supplement or replace what JAAS is today. I don't know if that
will ever happen, but if we as an ASF community desire it, then I
think it would be a great idea for further discussion.
Cheers,
Les
On Sun, Jun 8, 2008 at 10:13 AM, Noel J. Bergman <no...@devtech.com> wrote:
> How does JSecurity relate to existing standards, e.g., JAAS, JACC,
> WS-Security, etc.?
>
> The only reference I found is a comment in the slide show saying "Simplify
> or replace JAAS." Well JAAS is the Java standard in this space, and part of
> the Java core, so are we proposing a replacement or supplement to the JCP?
> I also see that JSecurity web support relies on a return to
> application-level security based on a filter, rather than rely on container
> management, which has evolved as a cornerstone of Java programming. The
> reliance on a filter is probably because JSecurity is not (yet?) integrated
> with the Java standards in the security space.
>
> It seems to me that there ought to be some support for Java specifications
> and container managed security, if projects such as Tomcat, Geronimo,
> Jetspeed, et al, are to consider JSecurity.
>
> This isn't a statement about suitability for Incubation, just a discussion
> point. :-)
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by Les Hazlewood <le...@hazlewood.com>.
Just a clarification:
JSecurity can be used in any environment - web or not, container or
not. The reason why the Filter approach is best known is that it is
the easiest to set up - Filters allow an 'interceptor' mechanism that
is common to any web container. When not using a Filter, you must use
AOP/interceptor mechanisms often specific to the containers themselves
- but it can be done (and is done) in environments today.
So, there is no limitation based on environment. I've even had
end-users say they're using JSecurity in a cell phone!
Cheers,
Les
On Sun, Jun 8, 2008 at 10:30 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Noel J. Bergman wrote:
>>
>> I also see that JSecurity web support relies on a return to
>> application-level security based on a filter, rather than rely on
>> container
>> management, which has evolved as a cornerstone of Java programming. The
>> reliance on a filter is probably because JSecurity is not (yet?)
>> integrated
>> with the Java standards in the security space.
>>
>
> I've been watching this proposal because I'm very interested in JSecurity as
> a whole, but I think Noel raises an interesting point here. At least in
> Websphere, you can have container-managed security on the method-level for
> EJBs, which doesn't have to be called form a webapp, so a filter-based
> approach couldn't provide this. I'd LOVE to be able to get rid of IBM's
> security subsystem and replace it with JSecurity, but if it can't allow the
> same sort of thing then I can't do that.
>
> Is that capability, or lack thereof, a limitation inherent in the approach
> JSecurity has taken, or is it just a case of a feature that is planned for
> down the road?
>
> Thanks,
> Frank
>
> --
> Frank W. Zammetti
> Author of "Practical DWR 2 Projects"
> and "Practical JavaScript, DOM Scripting and Ajax Projects"
> and "Practical Ajax Projects With Java Technology"
> for info: apress.com/book/search?searchterm=zammetti&act=search
> Java Web Parts - javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
> My "look ma, I have a blog too!" blog: zammetti.com/blog
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Incubate JSecurity Project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Frank W. Zammetti wrote:
> Noel J. Bergman wrote:
> > I also see that JSecurity web support relies on a return to
> > application-level security based on a filter, rather than rely on
container
> > management, which has evolved as a cornerstone of Java programming.
> > The reliance on a filter is probably because JSecurity is not (yet?)
integrated
> > with the Java standards in the security space.
>
> I've been watching this proposal because I'm very interested in
> JSecurity as a whole, but I think Noel raises an interesting point
> here. At least in Websphere, you can have container-managed security on
> the method-level for EJBs, which doesn't have to be called form a
> webapp, so a filter-based approach couldn't provide this. I'd LOVE to
> be able to get rid of IBM's security subsystem and replace it with
> JSecurity, but if it can't allow the same sort of thing then I can't do
> that.
Orthogonal issue, but potentially instructive -- what don't you like about
IBM's subsystem? FWIW, container-managed, role-based, authorization on web
contraints and EJB method permissions is straight from the specifications.
> Is that capability, or lack thereof, a limitation inherent in the
> approach JSecurity has taken, or is it just a case of a feature
> that is planned for down the road?
Possibly the latter, if they were to provide support for JACC
(http://java.sun.com/j2ee/javaacc/) aka JSR-115
(http://www.jcp.org/en/jsr/detail?id=115).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Incubate JSecurity Project
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Noel J. Bergman wrote:
> I also see that JSecurity web support relies on a return to
> application-level security based on a filter, rather than rely on container
> management, which has evolved as a cornerstone of Java programming. The
> reliance on a filter is probably because JSecurity is not (yet?) integrated
> with the Java standards in the security space.
>
I've been watching this proposal because I'm very interested in
JSecurity as a whole, but I think Noel raises an interesting point
here. At least in Websphere, you can have container-managed security on
the method-level for EJBs, which doesn't have to be called form a
webapp, so a filter-based approach couldn't provide this. I'd LOVE to
be able to get rid of IBM's security subsystem and replace it with
JSecurity, but if it can't allow the same sort of thing then I can't do
that.
Is that capability, or lack thereof, a limitation inherent in the
approach JSecurity has taken, or is it just a case of a feature that is
planned for down the road?
Thanks,
Frank
--
Frank W. Zammetti
Author of "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
for info: apress.com/book/search?searchterm=zammetti&act=search
Java Web Parts - javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
My "look ma, I have a blog too!" blog: zammetti.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Incubate JSecurity Project
Posted by "Noel J. Bergman" <no...@devtech.com>.
How does JSecurity relate to existing standards, e.g., JAAS, JACC,
WS-Security, etc.?
The only reference I found is a comment in the slide show saying "Simplify
or replace JAAS." Well JAAS is the Java standard in this space, and part of
the Java core, so are we proposing a replacement or supplement to the JCP?
I also see that JSecurity web support relies on a return to
application-level security based on a filter, rather than rely on container
management, which has evolved as a cornerstone of Java programming. The
reliance on a filter is probably because JSecurity is not (yet?) integrated
with the Java standards in the security space.
It seems to me that there ought to be some support for Java specifications
and container managed security, if projects such as Tomcat, Geronimo,
Jetspeed, et al, are to consider JSecurity.
This isn't a statement about suitability for Incubation, just a discussion
point. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org