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.
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.
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 :-)
--
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]
