You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Suhail M. Ahmed" <il...@mac.com> on 2005/02/05 20:20:45 UTC
jcr authentication and authorization
Hi,
My name is Suhail. I was on my way to implementing 170 before David set
me straight and pointed me the jack rabbit ri, I read from David's
earlier post that the team is working on A'nA. My own plan's with
regards to doing this was to specify a node type and build repository
adapters for LDAP to store and manage instances of the type. Given that
the repository could be configured with arbitrary storage adapters, one
could in principle store A'nA data any where. Then there is the issue
of using JAAS. JAAS itself is an abstraction on top of arbitrary
identity data stores. It would trivial to code, sya, a JCRLoginModule
that would allow JAAS to use the repository to access the identity
database. That should take care of authentication. Authorization on the
other hand is more involved. I would like to do two things at the
moment.
Build a JCRLoginModule to work against the default data store or
specify a new one to store A'nA data. This would require the default
store to be initialized with start up data for the initial set of
Principals.
At this point the login use case in the spec should work. Authorization
on the other hand is a different kettle of fish. If one does go the
Java permissions route, I suspect there will impact on the current code
base. Then there is the question of where and how policy data should be
stored. Naturally, I think policy should be accessed via the repository
as well.
Build a repository adapter for LDAP to store A'nA data. I propose LDAP
because I have experience with it. To this end I would like to
translate publicly available LDAP schemas to nodedefs. I have a few
days experience with JavaCC, if someone on this list can help me with
questions on using it to parse LDAP ldifs, I could have the whole bunch
translated in a jiffy.
As a start I have tried to define a Node to offer basic support for
authentication:
Namespace :
xmlns:ext="http://www.example.com/jcr/1.0" //extension namespace
xmlns:ana="http://www.example.com/jcr/acess/1.0" // authentication and
authorization namespace
<nodeType name="ext:simplePerson" isMixin="false"
hasOrderableChildNodes="false" primaryItemName="">
<supertypes>
<supertype>nt:base</supertype>
</supertypes>
<propertyDef name="jcr:created" requiredType="Date"
autoCreate="true" mandatory="true" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:cn" requiredType="String"
autoCreate="false" mandatory="true" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:sn" requiredType="String"
autoCreate="false" mandatory="true" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:givenName" requiredType="String"
autoCreate="false" mandatory="false" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:initials" requiredType="String"
autoCreate="false" mandatory="false" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:uid" requiredType="String"
autoCreate="false" mandatory="true" onParentVersion="COPY"
protected="true" multiple="false"/>
<propertyDef name="ana:userPassword" requiredType="Binary"
autoCreate="false" mandatory="true" onParentVersion="COPY"
protected="true" multiple="false"/>
</nodeType>
I lifted the properties from LDAP inetOrgPerson. I am not sure if I got
the onParentVersion correct. The type should also be guarded by a
access control mixin I suppose. How do I configure the repository so
that it knows the type above? Any ideas on how A'nA data is to be
stored? Is it best to store it in a different repository or in a
separate workspace? Is it possible to configure jack rabbit with
multiple repositories?
Have a nice evening.
regards
Suhail
Re: jcr authentication and authorization
Posted by "Suhail M. Ahmed" <il...@mac.com>.
Hi David,
On Feb 6, 2005, at 11:17 AM, David Nuescheler wrote:
>
>> Build a repository adapter for LDAP to store A'nA data. I propose LDAP
>> because I have experience with it. To this end I would like to
>> translate publicly available LDAP schemas to nodedefs. I have a few
>> days experience with JavaCC, if someone on this list can help me with
>> questions on using it to parse LDAP ldifs, I could have the whole
>> bunch
>> translated in a jiffy.
> is there a reason why you want to go through ldif instead of directly
> going to the ldap server?
I think there will be two types of architecture variants of how LDAP
and 170 will be used. In the first instance, LDAP servers being
configured as a repository underneath jackrabbit and the other instance
will be along the vision you elaborate below. I would like jackrabbit
to support both. What I am currently trying to do is to implement the
first variant. This would allow one to access LDAP using 170 API for
AnA purposes.
> i think an ldap-content-importer for jackrabbit would be great,
> basically you could point an import script using something
> like http://docs.sun.com/source/816-5618-10/ (or jndi) directly
> at an ldap server.
> then, first all the nodetypes get generated (if necessary)
> and then all the information is sucked out of the ldap server and
> stored into the content repository.
By virtue of implementing the first variant the second set of use cases
would be direct consequence. What I have in mind is the following:
Re: jcr authentication and authorization
Posted by David Nuescheler <da...@gmail.com>.
hi suhail,
> My name is Suhail. I was on my way to implementing 170 before David set
> me straight and pointed me the jack rabbit ri, I read from David's
> earlier post that the team is working on A'nA.
... by no means i wanted to "set you straight", just hint a direction ;)
> Authorization on the
> other hand is more involved. I would like to do two things at the
> moment.
> Build a JCRLoginModule to work against the default data store or
> specify a new one to store A'nA data. This would require the default
> store to be initialized with start up data for the initial set of
> Principals.
> At this point the login use case in the spec should work. Authorization
> on the other hand is a different kettle of fish. If one does go the
> Java permissions route, I suspect there will impact on the current code
> base. Then there is the question of where and how policy data should be
> stored. Naturally, I think policy should be accessed via the repository
> as well.
so do i. i think in the future "everything" should be stored in a repository.
all the data that is sitting in databases, filesystems, etc. becomes much
more useful once it put into a content repository, benefitting from versioning,
searching, fine-grained (un)structured "meta information" and a lot
of cool applications.
> Build a repository adapter for LDAP to store A'nA data. I propose LDAP
> because I have experience with it. To this end I would like to
> translate publicly available LDAP schemas to nodedefs. I have a few
> days experience with JavaCC, if someone on this list can help me with
> questions on using it to parse LDAP ldifs, I could have the whole bunch
> translated in a jiffy.
is there a reason why you want to go through ldif instead of directly
going to the ldap server?
i think an ldap-content-importer for jackrabbit would be great,
basically you could point an import script using something
like http://docs.sun.com/source/816-5618-10/ (or jndi) directly
at an ldap server.
then, first all the nodetypes get generated (if necessary)
and then all the information is sucked out of the ldap server and
stored into the content repository.
personally, i think one could take this even further and i think that a
content repository based ldap-server would be pretty much the best
thing since sliced bread (finally, people would get their
"user profiles" etc. versioned). so having an ldap server and
jndi layering on top of jcr would be great too.
> As a start I have tried to define a Node to offer basic support for
> authentication:
>
> Namespace :
> xmlns:ext="http://www.example.com/jcr/1.0" //extension namespace
> xmlns:ana="http://www.example.com/jcr/acess/1.0" // authentication and
> authorization namespace
>
> <nodeType name="ext:simplePerson" isMixin="false"
> hasOrderableChildNodes="false" primaryItemName="">
> <supertypes>
> <supertype>nt:base</supertype>
> </supertypes>
> <propertyDef name="jcr:created" requiredType="Date"
> autoCreate="true" mandatory="true" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:cn" requiredType="String"
> autoCreate="false" mandatory="true" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:sn" requiredType="String"
> autoCreate="false" mandatory="true" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:givenName" requiredType="String"
> autoCreate="false" mandatory="false" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:initials" requiredType="String"
> autoCreate="false" mandatory="false" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:uid" requiredType="String"
> autoCreate="false" mandatory="true" onParentVersion="COPY"
> protected="true" multiple="false"/>
> <propertyDef name="ana:userPassword" requiredType="Binary"
> autoCreate="false" mandatory="true" onParentVersion="COPY"
> protected="true" multiple="false"/>
> </nodeType>
>
> I lifted the properties from LDAP inetOrgPerson. I am not sure if I got
> the onParentVersion correct.
looks, ok to me...
> The type should also be guarded by a
> access control mixin I suppose.
i would assume.
> How do I configure the repository so
> that it knows the type above?
generally, jsr-170 excludes registration of new nodetypes from the
specification in v1.0. with respect to jackrabbit you should be able to
put them into the custom_nodetypes.xml (or register them through
the api) which i would assume is where you got the above snippet from.
[ for everybody who is looking for a more convenient way to
model nodetypes for now:
http://jsr170tools.day.com/crx/nodetypes/index.jsp , can also
be downloaded and used locally, the gui is not perfectly stable
yet, though ]
since i also think that jackrabbit should provide an internal
mechanism to authenticate (and authorize) i think that for
example a similar nodetype to the above nodetype should go
into the "built-in nodetypes", since in my mind it should
be part of the core-repository.
when nt-modelling something that is core to the repository
i would probably also lose the ldap-centric naming
convention like cn, sn, ... and name the properties according
to how we decide to call them in a content-repository domain.
obviously, the mapping between ldap-attributes and the
content properties plays an important role, in many of the
above cases.
> Any ideas on how A'nA data is to be
> stored?
> Is it best to store it in a different repository or in a
> separate workspace?
good question. personally, i could see the authentication
information in a separate workspace, a different repository
is something that could be simulated if someone implements
a jcr-based persistence manager. (anybody?)
> Is it possible to configure jack rabbit with
> multiple repositories?
personally, i think that one instance of jackrabbit should be
equivalent to one repository. but that's just my gut feeling
thanks & regards,
david
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97