incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <...@hazlewood.com>
Subject Re: [PROPOSAL] Incubate JSecurity Project
Date Fri, 30 May 2008 13:55:52 GMT
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
<james@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <jhaile@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


Mime
View raw message