>
> 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
