directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [vote] RMS - Realm Management System
Date Wed, 07 Apr 2004 06:48:52 GMT
Alex Karasulu wrote:
> 
>>-----Original Message-----
>>From: Noel J. Bergman [mailto:noel@devtech.com]
>>Sent: Wednesday, April 07, 2004 12:56 AM
>>To: Apache Directory Developers List
>>Subject: RE: [vote] RMS - Realm Management System
>>
>>
>>>This is a very high level framework for storing and managing relatively
>>>static information within an application domain or realm in a directory.
>>>It can store user's, groups and application permissions as well as
>>>aspects of a user's profile that are unrelated to security.  Basically
>>>RMS is a place to centralize information that is shared and changes
>>>relatively infrequently.
>>>
>>
>>>RMS is designed to sit on top of Janus and use any LDAP server.
>>
>>>We are also noticing that the RMS project fits more in line with
>>>our endeavors within the directory project.  It will also be able
>>>to use Janus and other API's to access static information stored
>>>perhaps in XML files.
>>
> 
> 
>>How does RMS work with, for example, a standard JNDI implementation?  
> 
> 
> Well it can use a JNDI provider for various aspects.  But mainly we 
> will create a JNDI based backing store for the information that RMS 
> serves.
> 
> 
>>What interfaces, services, features, does it need?  
> 
> 
> Different RMS providers will work with different interfaces.  So I 
> could use an XML based provider to access static XML for data.  Or 
> I can use a JDBC provider to get at the same information.  RMS is 
> designed to use different data models for its strengths.  A GUI tool 
> uses an RDBMS with a JDBC provider to master data within a write 
> optimized data store.  The content can then be check pointed (used 
> for rollbacks) and published out to a directory system for example.  
> When published to a directory the read optimized nature of LDAP 
> provides a fast highly available data store.
> 
> When storing certificates a directory is a natural fit.  Ultimately 
> if RMS stores CAs for applications then these are for organizational
> purposes best kept in directory although they can be stored 
> anywhere.  We could even store em in XML if we wanted to.
> 
> 
>>What kind(s) of entries and JNDI capabilities does it use?  
> 
> 
> It will store applications, permissions, users, groups and other 
> profile related entires.  Again it would use standard JNDI 
> interfaces when the JNDI provider is in use.
> 
> 
>>Would it work with Henri's Simple JNDI or an XML-specified JNDI 
>>context such as we use with a WebApp?  
> 
> 
> Absolutely if JNDI provider exists we can make it work with that 
> provider no mater what the storage medium is.

Sounds to me more like it would *be* the provider, IIUC; unless what you 
mean is support for federating data from other JNDI providers.  Do you see 
this as something that will be embedded in containers or just providing 
remote data services via LDAP, JDBC, SOAP, etc?
> 
> 
>>>From what you've
>>told me off-list, the answers are yes, but I want to bring this out with
>>everyone, and start to build a deeper understanding of how this relates
>>with
>>our Directory technologies.
> 
> 
> And I should have specified more of this in the earlier email.
> 
> Alex
> 
> 
Any plans to support XACML, SAML, WSS or other standards for the 
authorization and policy expression APIs?  Liberty?

Phil


Mime
View raw message