incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: [PROPOSAL] Incubate JSecurity Project
Date Fri, 30 May 2008 14:00:09 GMT
If you're curious, the two classes end-users use the most are the
Subject (,
and the Session
( -
acquired via subject.getSession();



On Fri, May 30, 2008 at 9:55 AM, Les Hazlewood <> 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
> <> wrote:
>> On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message