Hi Balajee, There are not any such diagrams. If anyone in the community would like to contribute some, we'd be grateful!
Regards, Les On Tue, Jul 14, 2009 at 4:37 AM, <[email protected]> wrote: > Hi Les, > > Thanks you for your explanation. > > Can I have any sequence flow diagram of JSecurity to understand how it > works internally between Classes for authorization, authentication, session > management. > > > > Thanks & Regards > > Balajee > > > > > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Les Hazlewood <[email protected]> > *Sent:* Monday, July 13, 2009 3:36 PM > > *To:* [email protected] > *Subject:* Re: Regarding Jsecurity usage in my project > > > > Hi Balajee, > > Because Shiro is a security framework and not a clustering/HA framework, we > rely on other mechanisms to achieve this. > > The best way to do this is to use an enterprise distributed caching/grid > framework such as TerraCotta, Coherence, GigaSpaces, etc. > > The way I handle this in my own applications is to write a SessionDAO > implementation that talks to the distributed cache. It performs CRUD > operations against the enterprise Cache API. You then configure the > enterprise cache to cluster the Session instances that are passed to the > SessionDAO. > > Then, because they are cached across the cluster, a > sessionDAO.read(sessionId) will return the session on any server in the > cluster. This allows transparent lookup and failover capabilities > automatically by relying on the enterprise cache to make sure the Session > objects are not lost if any one server fails. > > Cheers, > > Les > > On Mon, Jul 13, 2009 at 5:11 AM, <[email protected]> wrote: > > Hi Les, > > Thank you for your explanation. > > If we are using load balancing concept in my application how j security > will handle session management. i.e how it will update/ migrate sessions > between two server of load balancer > > > > Thanks & Regard > > Balajee > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Les Hazlewood <[email protected]> > *Sent:* Sunday, July 12, 2009 9:10 PM > *To:* [email protected] > *Subject:* Re: Regarding Jsecurity usage in my project > > > > Hi Les, > > > > > > > > I am working on a project with flex and java. I came across Jsecurity when I > > am evaluating security framework for my project. > > > > I gone through the samples and trying to understand Jsecurity. > > > > I have following question before I recommend Jsecurity for my project. > > > > > > > > We r planning to have users,groups,roles privileges for object. In JSecurity > > I didn’t get any information regarding user groups. Can I create groups and > > assign roles to groups? > > Of course you can, but Shiro doesn't provide any 'write' operations to > do this for you. The reason is that Shiro can't know ahead of time what > data model you will need, so it only performs 'read' operations from Realms > to do authentication and authorization checks. You typically make those > associations yourself in an application by calling a GroupManager/Service or > UserManager/Service (or something similar) and have those managers/services > make calls to DAOs that know about your data model and data source. > > Then your Realms can read from those same data sources to do the lookups > necessary to perform the security check.\ > > > > Shiro has different naming for these. They are as follows > usual name: jsecurity name > User: Subject > Group: PrincipalCollection > > > Oops, this one is incorrect. A Principal is an identifying attribute of a > Subject, aka user. For example, username, social security number, user id, > etc - these are all Principals. A PrincipalCollection is nothing more than > what its name implies - a collection of one or more Principals. A > PrincipalCollection exists to aggregate Principals for a subject from one or > more Realms. > > That is, if you log in and 2 realms are accessed - a JdbcRealm and an > LdapRealm, the JdbcRealm might contain a user id (primary key) and > permission information. The LdapRealm might contain that user's username, > first name, and last name. Each one of these identifying attributes from > both Realms is a Principal. The PrincipalCollection 'wraps' these > Principals from all Realms consulted during the authentication process so > they can be accessed by the application later - for example, > principalCollection.fromRealm("myJdbcRealm"). > > A Group on the other hand is not something that is supported natively at > the moment by Shiro because it is a convenience mechanism that does not > necessarily exist across most applications. > > I usually think of a Group in the following context: > > A Group is a named collection of one or more Users > A Role is a named collection of one or more Permissions > > If a Group has Roles and a User is assigned to a Group, then by transitive > association, you could think of the User 'having' the Group's Roles (as well > as any that might be directly assigned to that User). > > > > > Privilages: Permission > > > > I recommend you reading the QuickStart.java example to udnerstand how it > all works. Also the configuration file. It showys how to assign roles to > groups > > > > Is there any standard database setup(schema) needed to work with Is there > > any admin console developed for Jsecurity to assign/ modify users,groups > > ,privileges. > > There is not currently any such thing. The reason is that Shiro was > designed from the ground up to handle any security model. If we made an > admin console we would have to make many assumptions about the underlying > system. For example, most applications use Roles. Some use Groups and > Roles. Some applications never use Permissions. Some applications assign > Permissions directly to Users, while others never do this and only assign > Permissions to Roles and then assign Roles to Users to achieve a more > indirect (and more scalable) mapping. > > You can see the number of combinations of this getting pretty difficult to > deal with to support most applications' needs, which is why we don't have a > console to do this out-of-the-box - it would impose many assumptions on the > underlying data model that we can't control. > > Now - all of this being said, this is not the first request for such a > system, so I think we might be able to give this a try and see how it goes. > But I'm fairly certain something like this is a large enough effort that it > would probably need to wait until after 1.0 is released > > How session management is implemented. As my request comes from Flex > > > > client/Web browser, is it secure to use Jsecurity for session management. > > Yes, this works perfectly fine - I'm using it myself in a large > enterprise Flex application right now in fact. Because Flex requests (AMF > over HTTP) use the normal HTTP protocol, any session cookies set by the > Shiro WebSecurityManager will be sent back to the server with each Flex > invocation. You don't have to configure anything to get this to work - it > is already enabled. > > Is there any extension possible for secure payment transactions / usage of > > captcha for user identification. > > There is a Jira issue I believe for Captcha support, and it is not yet > implemented. There is no native support for native secure payment > transactions as these operations almost always rely on an application's > native data model as well as the payment provider being used. > > But I'm sure that if anyone wanted to help with either of these, we'd be > open to suggestions/contributions!!! > > Anyway, I hope that helped explain things. > > Cheers, > > Les > > >
