>-----Original Message-----
>From: Rafal Krzewski [mailto:[EMAIL PROTECTED]]
>Sent: Friday, December 08, 2000 2:48 AM
>To: Turbine
>Subject: Re: Policy Server
>
>
>Tracy Adewunmi wrote:
>
>> 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.
>
>We have only LDAPUserManager. DBSecurityService is used for
>roles/permissions.
>And it has some major hacks in it, which is the only reason why it is
>not
>included in Turbine yet :-)
>
>> 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).
>
>We are using OpenLDAP as our server. Every time Turbine connects to the
>server it authorizes itself as a single entity, no matter
>which data are
>accesses. This entity must be granted the rights to read and modify
>the data of all users in the system. This way only a single account
>(from the LDAP server's security point of view) needs to be created.
>This way we stay independent of the security mechanism existing in the
>server.
>
>Please see the the message,
>http://www.mail-archive.com/[email protected]/msg05995.html
>for my rationale for taking this approach.
>
>> 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.
>
>There is a new implementation of logging subsystem for Turbine
>underway.
>It will support logging to multiple files, and with help of log4j
>package
>to syslogd or remote logserver. It will be possible then, to direct
>audit messages to a specific file.
That sounds good. I *think* I've heard of log4j....did that come from
sourceforge? (just curious)
>
>The logging of authentication events needs to be written yet. It should
>be configurable throught the service properties (verbosity level:
>all events/only authentication events/only authentication
>failures/none,
>the name of the log to write to).
>
>You are wellcome to implement it and send patches to us, if you need
>this kind of functionality.
Ok. I'll make a pass at it as soon as we get the access control for the
portlets taken care of.
>
As I was making my most recent rounds in the TR.prop file, I noticed a
little line that we had commented out...it was the entry for the
turbine-security.log file. I've uncommented this line out and I'll see what
I get. (Jon, this is the lazy chic's way around reading through the code)
>Rafal
>
>PS. Somehow I don't see the connection between those questions (which
>are
> quite strigtforward) and your message about policy servers that
> really puzzled me :-)
>
We started off wanting just to be able to get Jetspeed to authenticate
against our Active Directory Service and looked to Turbine's new security
service for this. So I hadn't really delved deep into the layer at the
time...just enough for authentication. Folks over here were satifisied with
getting LDAP authentication working and then having an all or none approach
to viewing the portlets that authenticated users get to see. Since we'd
like to have finer grained access control for the portlets, I started
wondering if the security services layer was actually an entity that
enforces policy (a.k.a a policy server). So when the first round of
questions started to hit me.....I got all excited and stopped thinking. (I
know I'm inviting trouble with that one). I started hypothesizing and
theorizing and started wondering how Jetspeed would use these services. I
decided to ask my entry question hoping to get a simple "yes....you can view
the security services layer as a policy server" or "no....you shouldn't view
the security services layer as a policy server". Instead...as an intial
response I got....
But none the less, you have provided me with more insight than I could have
hoped for and for that I am appreciative.
>--
>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]
