You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gerhard Froehlich <g-...@gmx.de> on 2002/02/20 14:27:12 UTC
[simplestore] AccessControl
Hi Jouzas,
we talked about Security in the persistence classes
some days ago (read and write access). How about
using the java.security.acl interfaces for the
implementation or do you tend towards something
homegrown?
~Gerhard
"Eagles may soar, but weasels don't get
sucked into jet engines.
(Todd C. Somers)"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] alt. not JDBC Storage and AccessControl [was: AccessControl]
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
I started to implement mappings and xml metadata, I will generate parsers at
this time,
we will use some better xml parsing tools later.
> >Hi,
> >Do you read JAAS documentation ?
>
> Just started ;-).
>
> >I recomend to do it, it well documented and has examples.
> >Don't understand me wrong, It is very good to implement Acl
> >and it is possible to reuse Acl implementation for JAAS
> >based security implementation.
>
> I will look at it. TIA for the tip.
> I have in the moment some private stress. I hope I'll back
> in the code soon...
>
> ~Gerhard
>
> -----------------------------------
> Boren's Law: When in doubt, mumble.
> -----------------------------------
>
> >> Juozas,
> >>
> >> >As I understand you are working on security.
> >>
> >> ;) I try. Some questions:
> >> Acl => List which holds to each Principal a Set of AclEntry's
> >> AclEntry => entry in an Access Control List
> >> Permission => used to grant a particular type of access
> >> to a resource
> >> Principal => used to represent any entity, such as an
> >> individual, a corporation, and a login id.
> >>
> >> For me the Acl is a simple Hashmap, which holds for each
> >> Prinicpal a Set of AclEntry's. Key is the Principal and
> >> value is a Set of AclEntry's.
> >> There are two AclEntry with one READ and one WRITE Permission.
> >>
> >> In our case each Acl contains ony one AclEntry for an Principal,
> >> either READ or WRITE .
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] alt. not JDBC Storage and AccessControl [was: AccessControl]
Posted by Gerhard Froehlich <g-...@gmx.de>.
>Hi,
>Do you read JAAS documentation ?
Just started ;-).
>I recomend to do it, it well documented and has examples.
>Don't understand me wrong, It is very good to implement Acl
>and it is possible to reuse Acl implementation for JAAS
>based security implementation.
I will look at it. TIA for the tip.
I have in the moment some private stress. I hope I'll back
in the code soon...
~Gerhard
-----------------------------------
Boren's Law: When in doubt, mumble.
-----------------------------------
>> Juozas,
>>
>> >As I understand you are working on security.
>>
>> ;) I try. Some questions:
>> Acl => List which holds to each Principal a Set of AclEntry's
>> AclEntry => entry in an Access Control List
>> Permission => used to grant a particular type of access
>> to a resource
>> Principal => used to represent any entity, such as an
>> individual, a corporation, and a login id.
>>
>> For me the Acl is a simple Hashmap, which holds for each
>> Prinicpal a Set of AclEntry's. Key is the Principal and
>> value is a Set of AclEntry's.
>> There are two AclEntry with one READ and one WRITE Permission.
>>
>> In our case each Acl contains ony one AclEntry for an Principal,
>> either READ or WRITE .
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] alt. not JDBC Storage and AccessControl [was: AccessControl]
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
Do you read JAAS documentation ?
I recomend to do it, it well documented and has examples.
Don't understand me wrong, It is very good to implement Acl
and it is possible to reuse Acl implementation for JAAS
based security implementation.
> Juozas,
>
> >As I understand you are working on security.
>
> ;) I try. Some questions:
> Acl => List which holds to each Principal a Set of AclEntry's
> AclEntry => entry in an Access Control List
> Permission => used to grant a particular type of access
> to a resource
> Principal => used to represent any entity, such as an
> individual, a corporation, and a login id.
>
> For me the Acl is a simple Hashmap, which holds for each
> Prinicpal a Set of AclEntry's. Key is the Principal and
> value is a Set of AclEntry's.
> There are two AclEntry with one READ and one WRITE Permission.
>
> In our case each Acl contains ony one AclEntry for an Principal,
> either READ or WRITE .
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] alt. not JDBC Storage and AccessControl [was: AccessControl]
Posted by Juozas Baliuka <ba...@centras.lt>.
----- Original Message -----
From: Gerhard Froehlich <g-...@gmx.de>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Sent: Saturday, February 23, 2002 1:18 PM
Subject: RE: [simplestore] alt. not JDBC Storage and AccessControl [was:
AccessControl]
> Juozas,
>
> >As I understand you are working on security.
>
> ;) I try. Some questions:
> Acl => List which holds to each Principal a Set of AclEntry's
> AclEntry => entry in an Access Control List
> Permission => used to grant a particular type of access
> to a resource
> Principal => used to represent any entity, such as an
> individual, a corporation, and a login id.
>
> For me the Acl is a simple Hashmap, which holds for each
> Prinicpal a Set of AclEntry's. Key is the Principal and
> value is a Set of AclEntry's.
> There are two AclEntry with one READ and one WRITE Permission.
>
> In our case each Acl contains ony one AclEntry for an Principal,
> either READ or WRITE .
>
> What do you think?
Yes, it must be trivial to implement. A single problem is login , I don't
see any
authentication in Acl we must usesomething this kind :
AuthenticationManager.login("user","password");
object.setSomething(something);//throws security exception if "user" has no
permission on method
// or some pluged AuthorizationManager
decides to throw this;
login implementation :
login(String user, String password){
// weak keys, not values !!!
weakMap.put(Thread.currentThread(), new PrincipalImpl(user));
}
Principal currentPrincipal(){
return (Principal)weakMap.get(Thread.currentThread());
}
// code in proxy :
invoke(......){
Principal p = AuthenticationManager.currentPrincipal(); // null if not
authenticated
check(p, .....);
<scip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] alt. not JDBC Storage and AccessControl [was: AccessControl]
Posted by Gerhard Froehlich <g-...@gmx.de>.
Juozas,
>As I understand you are working on security.
;) I try. Some questions:
Acl => List which holds to each Principal a Set of AclEntry's
AclEntry => entry in an Access Control List
Permission => used to grant a particular type of access
to a resource
Principal => used to represent any entity, such as an
individual, a corporation, and a login id.
For me the Acl is a simple Hashmap, which holds for each
Prinicpal a Set of AclEntry's. Key is the Principal and
value is a Set of AclEntry's.
There are two AclEntry with one READ and one WRITE Permission.
In our case each Acl contains ony one AclEntry for an Principal,
either READ or WRITE .
What do you think?
>I am going to write more tests, I know we will have some problems with
>transactions,
Wise guy....
>I will review OjectBridge today, I believe I will find good ideas for
>mapping.
>And we need to start implementation for some "Not JDBC Storage", we will
>made les bugs in design if we will have two Storage implementations.
>I thaught abaut BerkleyDB ( transactional BTree implementation ), but
>there are some good JAVA implementation on sourceforge.
Ok your choice! As you know I use Jisp in Cocoon, but there's a problem
with long String keys in the moment (Scott will fix this in his new
releas). But this point is very important and maybe there are some
better impl. around.
>I think we will see a lot of dissadvantages in design then we start to
>implement some BTreeStorage.
Ambitous ;), but kool. I think that's not that hard.
~Gerhard
---------------------------------------------
Very funny, Scotty. Now beam down my clothes.
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] AccessControl
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
As I understand you are working on security.
I am going to write more tests, I know we will have some problems with
transactions,
I will review OjectBridge today, I believe I will find good ideas for
mapping.
And we need to start implementation for some "Not JDBC Storage", we will
made les bugs in design if we will have two Storage implementations.
I thaught abaut BerkleyDB ( transactional BTree implementation ), but
there are some good JAVA implementation on sourceforge.
I think we will see a lot of dissadvantages in design then we start to
implement some
BTreeStorage.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] AccessControl
Posted by Juozas Baliuka <ba...@mwm.lt>.
----- Original Message -----
From: "Gerhard Froehlich" <g-...@gmx.de>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, February 21, 2002 12:37 PM
Subject: RE: [simplestore] AccessControl
> >> Ok I see. I will start with some simple read and write security impl.
> >> I think that comes "permission on method and class" relativ near, or?
> >> For that I will create an own sub-package
> >..simplestore.persistence.security. Ok?
> >> This will be the place for java.security.acl implementations. I will
start
> >> implementing this and then we will see how this object stuff fits in.
> >>
> >> Maybe PersistenProxy gets an second constructor, or something else to
> >handle
> >> this securtiy things or not.
> >>
> >> What do you think?
> >1.Yes permission on method or class is the same for implementation.
> >2.implementation for java.security.acl.* is good idea
>
We need some interface for security plugins only, like "SecurityManager"
"Context" can be factory, for all plugins
> Ok kool. BTW I see no need to implement an extra interface for that. Just
> implementing the securtiy.acl interfaces is ok, or? Or do you want an
extra
> interfaces in our commons.simplestore.persistence package?
>
> ~Gerhard
>
> -----------------------------------
> Boren's Law: When in doubt, mumble.
> -----------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] AccessControl
Posted by Gerhard Froehlich <g-...@gmx.de>.
>> Ok I see. I will start with some simple read and write security impl.
>> I think that comes "permission on method and class" relativ near, or?
>> For that I will create an own sub-package
>..simplestore.persistence.security. Ok?
>> This will be the place for java.security.acl implementations. I will start
>> implementing this and then we will see how this object stuff fits in.
>>
>> Maybe PersistenProxy gets an second constructor, or something else to
>handle
>> this securtiy things or not.
>>
>> What do you think?
>1.Yes permission on method or class is the same for implementation.
>2.implementation for java.security.acl.* is good idea
Ok kool. BTW I see no need to implement an extra interface for that. Just
implementing the securtiy.acl interfaces is ok, or? Or do you want an extra
interfaces in our commons.simplestore.persistence package?
~Gerhard
-----------------------------------
Boren's Law: When in doubt, mumble.
-----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] AccessControl
Posted by Juozas Baliuka <ba...@mwm.lt>.
> Ok I see. I will start with some simple read and write security impl.
> I think that comes "permission on method and class" relativ near, or?
> For that I will create an own sub-package
..simplestore.persistence.security. Ok?
> This will be the place for java.security.acl implementations. I will start
> implementing this and then we will see how this object stuff fits in.
>
> Maybe PersistenProxy gets an second constructor, or something else to
handle
> this securtiy things or not.
>
> What do you think?
1.Yes permission on method or class is the same for implementation.
2.implementation for java.security.acl.* is good idea
3. Permission on object is optional, because it is impossible to implement
for all
situations, but user must have possibility to plug his implementation
specific security.
invoke( ... method ...){
checkCallerIsMappedToSomeRole( caller, method );
usedDefinedInvoke(caller, object, method , params );
// it can be used for security, but used can decide to invoke any action,
like validation or
// assert :
// "assert( param[0] != null ) "
..................................................................
}
>
> ~Gerhard
>
> --------------------------------------------
> Give me ambiguity or give me something else.
> --------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] AccessControl
Posted by Gerhard Froehlich <g-...@gmx.de>.
Juozas,
>> > 1. " Subject Has Permission on Class"
>> > 2. " Subject Has Permission on Method"
>> > 3. " Subject Has Permission on Object"
>>
>> ...with a simple solution... Hmm do we need a own interface for that to
>> capsulate this things? I started from scratch today design one, then I
>> clashed with the Java API.
>>
>> Somehow I like the simple solution in this article:
>> <http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-proxy.html>
>
>Yes, this is "Subject Has Permission on Method" and
> "Subject Has Permission on All Methods" <=>"Subject
>Has Permission on Class",
Yes
>but " Subject Has Permission on Object" is not trivial it
>means check like this:
>invoke(..., method ,...){
>// checkInvokeMethod( caller, method ); " Subject Has Permission on Method"
> checkPermission( caller, method, OID );// aditional param OID
>}
> example :
>
> AuthenticationManager.login("baliuka","baliuka");// login to current Thread
>......................................
>// next always throws Authorization exeption if have implementation for "
>Subject Has
>// Permission on Object"
>MyUserInterface user = user.find( MyUserInterface.class, "NotBaliuka" );
> user.setPassword("baliuka");
Ok I see. I will start with some simple read and write security impl.
I think that comes "permission on method and class" relativ near, or?
For that I will create an own sub-package ..simplestore.persistence.security. Ok?
This will be the place for java.security.acl implementations. I will start
implementing this and then we will see how this object stuff fits in.
Maybe PersistenProxy gets an second constructor, or something else to handle
this securtiy things or not.
What do you think?
~Gerhard
--------------------------------------------
Give me ambiguity or give me something else.
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] AccessControl
Posted by Juozas Baliuka <ba...@mwm.lt>.
> > 1. " Subject Has Permission on Class"
> > 2. " Subject Has Permission on Method"
> > 3. " Subject Has Permission on Object"
>
> ...with a simple solution... Hmm do we need a own interface for that to
> capsulate this things? I started from scratch today design one, then I
> clashed with the Java API.
>
> Somehow I like the simple solution in this article:
> <http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-proxy.html>
Yes, this is "Subject Has Permission on Method" and
"Subject Has Permission on All Methods" <=>"Subject Has Permission on
Class",
but " Subject Has Permission on Object" is not trivial it means check like
this:
invoke(..., method ,...){
// checkInvokeMethod( caller, method ); " Subject Has Permission on Method"
checkPermission( caller, method, OID );// aditional param OID
}
example :
AuthenticationManager.login("baliuka","baliuka");// login to current Thread
......................................
// next always throws Authorization exeption if have implementation for "
Subject Has
// Permission on Object"
MyUserInterface user = user.find( MyUserInterface.class, "NotBaliuka" );
user.setPassword("baliuka");
>
> ~Gerhard
>
> *---------------------------------------------------------*
> | Contrary to popular belief, UNIX is user-friendly. It |
> | just happens to be selective on who it makes friendship |
> | with. |
> | - Richard Cook |
> *---------------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] AccessControl
Posted by Gerhard Froehlich <g-...@gmx.de>.
Juozas,
>Hi,
>Yes we it is better to use standard interfaces, we can use JAAS,
>I am not sure, but it seems JAAS is added to JDK 1.4 and it is possible
>to download it for JDK 1.3. It has configuration files,
>plugable login modules , principals, groups ... , but I think we will need
>it only
>for authentication ( LoginContext, LoginModule, Subject ), authorization
>must be more flexible.
>we will need this logic :
> 1. " Subject Has Permission on Class"
> 2. " Subject Has Permission on Method"
> 3. " Subject Has Permission on Object"
>JAAS will not help for this authorization, it because we must grant some
>permissions on
>runtime.
>Good examples for security (Authorization) design is jakarta-slide and
>www.jboss.org
KISS, KISS and KISS ;). When we think in jakarta-commons terms
we should keep dependencies to other libaries low. I tend to
> 1. " Subject Has Permission on Class"
> 2. " Subject Has Permission on Method"
> 3. " Subject Has Permission on Object"
...with a simple solution... Hmm do we need a own interface for that to
capsulate this things? I started from scratch today design one, then I
clashed with the Java API.
Somehow I like the simple solution in this article:
<http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-proxy.html>
~Gerhard
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] AccessControl
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
Yes we it is better to use standard interfaces, we can use JAAS,
I am not sure, but it seems JAAS is added to JDK 1.4 and it is possible
to download it for JDK 1.3. It has configuration files,
plugable login modules , principals, groups ... , but I think we will need
it only
for authentication ( LoginContext, LoginModule, Subject ), authorization
must be more flexible.
we will need this logic :
1. " Subject Has Permission on Class"
2. " Subject Has Permission on Method"
3. " Subject Has Permission on Object"
JAAS will not help for this authorization, it because we must grant some
permissions on
runtime.
Good examples for security (Authorization) design is jakarta-slide and
www.jboss.org
> Hi Jouzas,
> we talked about Security in the persistence classes
> some days ago (read and write access). How about
> using the java.security.acl interfaces for the
> implementation or do you tend towards something
> homegrown?
>
> ~Gerhard
>
> "Eagles may soar, but weasels don't get
> sucked into jet engines.
> (Todd C. Somers)"
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>