Also, on the Object data model front - we definitely cannot enforce
an Object model on end users. Legacy systems, 3rd party APIs, and
different developers viewpoints would make this very impractical -
most people would never want to implement those interfaces, plus it
would force an API lock-in of JSecurity into your data model (not
good - violates the Low Coupling/High Cohesion principal).
But this is why the sample apps exist - to show people how the
JSecurity developers prefer writing our own applications and data
models. You can choose to mirror your data model against what we
use in the samples if you like, but we can't force one :/
Regards,
Les
On Thu, Feb 26, 2009 at 12:41 PM, Shay Matasaro <[email protected]
<mailto:[email protected]>> wrote:
Thanks for the replies guys.
so its up to me to implement all permissions related aspects
including wildcards , and instance levels ones, seems a bit tricky ?
I think that the end goal for a security framework should include
top to bottom interfaces and *Object *data model (definitely not
table schemes , just class and interface definitions) , this
approach would still allow developers to wire the framework to any
data storage, but the model will enforce proper architecture.
for an experienced developer some of these design decisions ,
might look simple , but junior and intermediate devs require some
guidelines especially when doing first time implementations.
Thanks,
Shay
Les Hazlewood wrote:
Hi Shay,
Daniel is correct. Data models (users, groups, roles,
permissions, etc, etc) vary widely across applications -
JSecurity can't, and shouldn't, expect or enforce data model
APIs on framework end-users.
So, the Realms perform simple translation from an
application's data model to what JSecurity expects, in the
form of AuthenticationInfo and AuthorizationInfo return values
that JSecurity does understand.
When writing an application, I do all CRUD operations for
security data - users, roles, etc in a different place - e.g.
a UserManager. The Realm implementation just delegates to the
UserManager (or similar) to get the data necessary for
JSecurity, then transforms it as necessary, and returns it.
It stays read-only while the UserManager does
read/write/update.
Your Realm can interact with a datasource directly too if you
want - it is up to you. I just choose to delegate since the
UserManager already has a DAO that interacts with the
datasource - no need for me to use the datasource APIs in two
different places. But it is still your choice dependening on
your needs/desires.
If you want a head-start in creating your own data model that
will work very well, either with or without JSecurity, take a
look at the Spring/Hibernate sample application that ships
with JSecurity's distribution. It has User, Role, and
Permission objects all queried/saved by Hibernate. Even if
you don't use Hibernate, the data model in that sample app
will give you ideas.
Cheers,
Les
On Thu, Feb 26, 2009 at 10:50 AM, Daniel J. Lauk
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
Hello, Shay.
AFAIK the JSecurity framework only provides interfaces for
"consuming"
(=reading) information.
(Side note: I'm not sure, if the DAO pattern considers
write access in
the first place)
Of course, when you write your implementation of the
org.jsecurity.realm.Realm interface you can add such
functionality to
your implementing class.
Cheers,
DJ
2009/2/26 Shay Matasaro <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>:
> Hi Les,
>
> Thank you for the prompt reply.
>
> i have been reviewing all Realm implementations , but I am
obviously missing
> something , since implementing a custom realm only requires
implementing 2
> DB queries.
>
> what i don't see , is where does the DB persistence take
place ,
i.e.
> persisting new users, roles, groups , permissions; I
assume that
i need to
> implements all of these, by extending existing classes.
>
> do i have to implement my own token, user, account, role,
group
, etc..?
> or are there specific extension point that i can hook
into , without
> overriding the whole model?
>
>
> Thanks,
> Shay
>
>
>
> Les Hazlewood wrote:
>>
>> Hi Shay,
>>
>> JSecurity can use any data source - it does that by
wrapping
access to
>> that data source in a Realm implementation:
>>
>>
http://www.jsecurity.org/api/org/jsecurity/realm/Realm.html
>>
>> A Realm is essentially a security-specific DAO, so you can
communicate
>> with any back-end you need. Check out the Sample
applications
in the
>> JSecurity distribution, as well as some of the Realm
implementations here:
>>
>>
>>
http://svn.apache.org/repos/asf/incubator/jsecurity/trunk/core/src/org/jsecurity/realm/
>>
>> Look at the text, jndi, ldap sub packages for ideas, as
well as
the sample
>> applications that ship with JSecurity's distribution.
>>
>> I hope that helps!
>>
>> Cheers,
>>
>> Les
>>
>> On Thu, Feb 26, 2009 at 8:53 AM, Shay Matasaro
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
>>
>> Hi All,
>>
>> I ran into JSecurity yesterday and it looks very
promising, i'd
>> like to add it to my web service application.
>>
>> The only hurdle to cross is the fact that my app uses
its own
>> "object oriented DB" ; i would therefore like to
customize
>> Jsecurity to use our own data layer.
>>
>> is it possible to customize just the low-level db
access , and
>> allow JSecurity to maintain all the great features
that it
offers
>> without rewriting all aspects?
>>
>> if so what is the bare minimum list of objects and
interfaces that
>> i need to extend in order to achieve that goal (this
is a
new app
>> , so i don't have to align with any existing table
schema).
>>
>> To the project developers , Great Job! , the library
seems very
>> simple and easy to use, and after messing about with
JAAS for
>> awhile , i can really value simplicity.
>>
>> Thanks,
>> Shay
>>
>>
>>
>>
>
>
