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 <[EMAIL PROTECTED]> 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 > <[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]
