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 <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
