Thanks Rafal for your insight.
I recall reading on the list that you and a friend of yours were
implementing an LDAPSecurityService and its accompanying UserManagement
classes. While waiting for your official version of an
LDAPSecurityService/LDAPUser/LDAPUserManager etc. classes, I have gone ahead
and tried to create my own version. (which I'm sure are hacks compared to
what yours :-)). I haven't implemented all of the methods required by the
interfaces, just the ones neccessary for authentication and to get Jetspeed
running and happy.
The questions about policy came up when I was trying to implement
LDAPSecurityService.getACL(). Eventually, we'd like portlets to be aware of
aci. Currently, we are using MSFT's ADS to store user data and do our AAA
stuff. Is your LDAPSecurityService implementation LDAP provider agnositic?
Seemingly, and I may be all mixed up with this, Netscape's Directory Server
holds all its access control data directly in LDAP while ADS only stores a
pointer to access control information and it stores the actual data using
some sort of weird flat file/registry combination. If your
LDAPSecurityService is vendor neutral, would you mind sharing how you
overcame this limitation? (I won't be too saddened if you tell me just to
wait and see).
Jon, to your question about auditing: I was thinking that there could be a
security.log that would log the access attempts for authorization and
authentication both valid and invalid. For authentication, the audit message
would include the full DN of the user requesting authentication; while
authorization audit messages would include that + the requested permission
name and the DN of the requested resource. I'm not sure if turbine.log does
something similar.
--Tracy
>-----Original Message-----
>From: Rafal Krzewski [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, December 06, 2000 12:34 PM
>To: Turbine
>Subject: Re: Policy Server
>
>
>Tracy Adewunmi wrote:
>
>> Still considering myself a newbie to Turbine, I'll take your
>candor, Jon, as
>> interesting.
>
>Jon scared more newbies off the list than you can imagine.
>When he is in
>bad mood, you just have to cope with him :-)
>
>
>> At any rate, I was expecting the security services provided
>by Turbine to
>> also provide methods such as getPolicy/setPolicy,
>getRealm/setRealm, and
>> also auditing functionality. I realize I neglected to
>include the later in
>> my definition of what a policy server does but this is definitely
>> functionality that should exist in a entity that enforces
>policy. How is
>> security auditing handled within Turbine?
>
>Right now, the security system is implemented independently from the
>security mechanisms that Java platform provides (in java.security
>package) and that is found in the JAAS extension package.
>I know the JAAS specification and I think it has a lot of potential.
>However, it seems that is not yet very mature and the application
>servers available do not support it. This is why Turbine tries
>to implement security internally, independently of any security
>mechanisms that the JVM and/or application server would (or
>would not) provide.
>I expect that this situation will gradually change. When the
>application
>servers support JAAS based single sign on authentication, and
>JAAS based
>authorization mechanisms throughtout the application server, using
>container managed security will become practical. The proper
>strategy to
>take for Turbine when this happens will be providing a LoginModule that
>will use a directory service as the data store, and will provide
>mechanism for administering user accounts and role mapping from
>within the application itself.
>
>
>> One immediate question that came to my mind was if I wanted
>to use the
>> static getPolicy() method provided by the
>java.security.Policy object, how
>> would I go about doing this in Turbine if there is no
>inherit mechanism for
>> setting policies? I suppose I was looking for Turbine to
>provide a "Policy"
>> object. I'll spend more time with the
>AccessController/AccessControlList
>> objects and maybe I'll find the answers to my questions there.
>
>There is no direct relationship between AccessControlList and
>java.security classes. They serve similar purpose, that's all.
>
>
>> My intentions were not to critize...just to inquire. I
>realize that Rafeal
>> and yourself and all the other developers working on the
>security service
>> are quite busy and may not have time for misguided policy
>server questions,
>> but I figured it was worth a shot.
>
>Ideed, I was the person responsible for the recent changes to the
>security system. If you have more questions, don't heistate to ask.
>
>Rafal
>
>--
>Rafal Krzewski
>Senior Internet Developer
>mailto:[EMAIL PROTECTED]
>+48 22 8534830 http://e-point.pl
>
>
>
>------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
>Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
