Re: role based authorization -> dynacl module?

[Daniel Tröder]

Hello,

On 04/24/2018 04:28 PM, Shawn McKinney wrote:
>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>>  wrote:
>> 
>> I am in the process of implementing a role concept via ACLs and
>> hope for a hint so that I don't invent the wheel a second time.
>> 
> 
> I applaud your decision to not reinvent the wheel but have doubts
> about using ACL’s to accomplish (more later)
> 
>> 
>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>>  wrote:
>> 
>> Specifically, it is about identity management for schools. A
>> user (object) can have several roles in multiple schools.
>> Permissions on other LDAP objects can thus differ depending on
>> the role(s) the user and the object have in the same school(s).
>> 
> 
> Classic RBAC scenario for sure.  Nice job using a standards-based
> approach btw.
Thanks. I wasn't completely... "complete" - about our project. So in
the interest of disclosure: ;)
The product is not new, but exists for some years now
(https://www.univention.com/products/ucsschool/). It is completely
open source and free as in beer (except support ofc).
The LDAP tree is replicated from the master to >=1 LDAP slave per
school. All of a schools LDAP objects are in a ou=.. subtree.
For security reasons the replication to the LDAP servers in the school
slaves is "selective": only global (above ou=..) objects and their own
OU subtree is replicated to each slave. With the exception of user
objects, which can "belong" to multiple schools (OUs) by having them
listed in a "school" attribute (and their groups as well). The ACLs
are written so that user objects and their references (groups) can
also be replicated to those "additional" OUs.
There are three hard coded roles (staff, student, teacher) and the
ACLs are getting really hard to maintain (for example
https://github.com/univention/ucs-school/blob/4.3/ucs-school-ldap-acls-master/65ucsschool#L124).
As we want to be able to add more roles without having an ACL
explosion and customers are asking for ways to query the LDAP for
"role@school", we are now investigating new approaches to authorization.

>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>>  wrote:
>> 
>> For example, a user could have been assigned the following roles
>> that are scattered over several schools: → "Teacher" in school 1 
>> → "School admin" in school 2 → "Parent" in school 3 → both
>> "Teacher" and "Staff" in school 4
>> 
>> ACLs should now be defined accordingly, e.g. → the role "teacher"
>> at school X can reset the password for the role "student" at
>> school X → the role "teacher" at school X *cannot* reset the
>> password for the role "student" of school Y → the role "school
>> administrator" at school X can reset the password for the roles
>> "student" and "teacher" at school X → ...
> 
> Why use ACL’s for fine-grained authZ?
> 
> It’s drawbacks, - Not standard / LDAPv3 server lock-in (might not
> be a problem for you)
Our main product is a Linux distribution. UCS@school is kind of an
addon. An LDAP server has been until now the right answer for the
multitude of services that can be installed in a Linux distribution.

> - difficult to maintain and test (complex)
Definitively.

> To determine if necessary another question - how are your
> applications interacting with the directory.  Are they connecting
> using LDAPv3 operations (like search and bind), or is there are
> higher level abstraction in place, (like mod_authnz_ldap)?
There's both: a Python based API that abstracts LDAP objects as Python
objects, but there are a lot of services that query the LDAP directly
- not to mention all the 3rd party software from ISVs.

>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>>  wrote:
>> 
>> So far I have not seen any way to map such a construct via groups
>> or sets without including a separate ACL for each group, which is
>> a performance issue. Is there another way to map the role concept
>> besides implementing an own dynacl module?
> 
> There are many ways to achieve RBAC using LDAP.  Typically these
> other methods will use a library that gets imbedded into your
> application to use for the security checks. That way the directory
> ACL’s remain simple, and the bits corresponding to the policy live
> inside of objects that are stored within it, not in metadata for
> its config.
That'd be much simpler to maintain... and faster to extend. But as I
wrote above, not an option.

On the positive side: I do like that authorization is as near to the
data as possible. If the database makes both authentication and
authorization, I won't have to worry about anyone coming between my
code and the data, just because I forgot a firewall setting.

Greetings
Daniel



signature.asc
Description: OpenPGP digital signature

Re: role based authorization -> dynacl module?

[Daniel Tröder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 04/24/2018 05:04 PM, Michael Ströder wrote:
> Shawn McKinney wrote:
>> Why use ACL’s for fine-grained authZ?
>> 
>> It’s drawbacks, - Not standard / LDAPv3 server lock-in (might not
>> be a problem for you) - difficult to maintain and test (complex)
> 
> You have both of these issues for every non-trivial access control 
> system. Especially you need automated tests.
> 
>> To determine if necessary another question - how are your 
>> applications interacting with the directory.  Are they
>> connecting using LDAPv3 operations (like search and bind), or is
>> there are higher level abstraction in place, (like
>> mod_authnz_ldap)?
> 
> That's the real question: Does the end-user ever impersonate
> directly on the LDAP connection (optionally via a web
> application).
More and more services are moving towards SAML, OpenID etc., so one
day we may be able to shield clients from the actual database. But for
now a lot of our and 3rd party software access the LDAP directory
directly.

Greetings
Daniel
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEETmV9Y92VyKk8bwJc663P4/qAgV0FAlrfcI8ACgkQ663P4/qA
gV3J7w/+J3pUIUhabJPlrq9cbkXhk1+MawNtGZQzwPuIusDI9Z5sVCZDKSpiT2aT
PxW6Y6b6obZiwTmMPjU4sOXV8yr4RNSDhQIdqsi0clgyPIMHHVHoCPMH6qQpYvB7
rBj+UTqcDWwclfYI6/LPewSSIiVsSrUi9rFgl3NORcEQb8geUGgWjYecQD0bTnwg
yYciMlB3lgku20h1ZeRYRD3N3yURnR40I6kzXATednngEuvma+Vm35N9OsU8hKA1
k9EQFFrNg9jbV+npK62UefE+0leLGT6y0u93EOmYQP0/2E+M2rGVKWqXhoBwtBqr
iXbXT7PasXZVoHBTnNXODKvOz2Eg2v/pjVlvEV2vwVnBjzNuly+e2I7fzA8EakVm
6TON7r+0zZFO5CzR4a+WerAR5iOVb/+9FlLsTZ6N2pB4TDgkZlEBDEXvidSnA+np
w8plI9S9br0jVTHCrxH/ISrFY0IJU5Tsh8Jd/YybU1cAL+grIga41rpuCbwVWJv7
9EJekzM/t9iCOr52uLexspiHpc0pdvuGiNfPIzSg4n6h8Sw3I50EXF4/RsJAytqS
y5Egz701vSj2G2zB4VtUZxaOb4aZhc8VLFRtsYPSt/Jxyh9dGs/UXsxn/5Hxgr8S
6srEL+WPq5PbqUZAY9cBM10P1C0/IscM+Xc4umtXotbKhbl1Uc8=
=vyvG
-END PGP SIGNATURE-

Re: role based authorization -> dynacl module?

[Daniel Tröder]

Hello,

On 04/22/2018 05:57 AM, Howard Chu wrote:
> Daniel Tröder wrote:
>> Hello everyone,
>>
>> I am in the process of implementing a role concept via ACLs and hope for
>> a hint so that I don't invent the wheel a second time.
>>
>> Specifically, it is about identity management for schools. A user
>> (object) can have several roles in multiple schools. Permissions on
>> other LDAP objects can thus differ depending on the role(s) the user and
>> the object have in the same school(s).
>>
>> For example, a user could have been assigned the following roles that
>> are scattered over several schools:
>> → "Teacher" in school 1
>> → "School admin" in school 2
>> → "Parent" in school 3
>> → both "Teacher" and "Staff" in school 4
>>
>> ACLs should now be defined accordingly, e.g.
>> → the role "teacher" at school X can reset the password for the role
>> "student" at school X
>> → the role "teacher" at school X *cannot* reset the password for the
>> role "student" of school Y
>> → the role "school administrator" at school X can reset the password for
>> the roles "student" and "teacher" at school X
>> → ...
>>
>> So far I have not seen any way to map such a construct via groups or
>> sets without including a separate ACL for each group, which is a
>> performance issue.
>> Is there another way to map the role concept besides implementing an own
>>   dynacl module?
> 
> I think a dynacl module is your only choice. Most people miss the
> difference between roles and groups - group membership applies all the
> time. Once you're a member of a group, the privileges of that group are
> omnipresent.
OK - good to know we might be on the right track.

> Whereas, membership in a role grants you these privileges *only for as
> long as you assert that role* and adopting a role is a temporary,
> bounded activity.
> 
> So you need, at the least, in an LDAP context, an exop that says "assume
> role X" and the corresponding "drop role X". Without these two
> primitives, you don't actually have roles or role-based access control.
> LDAP's spec for proxy authorization might be sufficient for this purpose.
I read the rfc4370. It's very cool - it'd allow us to implement real
roles. But AFAICS it requires the clients to actively request its use
though. As our IDMs LDAP is accessible to 3rd parties, I don't think
that will work for us.

In the meantime my colleague has written a (proof of concept) dynacl
module "rolecmp".
The proposed solution works with two attributes:
* school: list of schools a user "belongs to" e.g. ['schoolA', 'SchoolB']
* role: list of "role:school" pairs describing the role(s) an object
has, when accessing other objects of the same school, e.g.:
['teacher:schoolA', 'student:SchoolB', 'teacher:schoolZ',
'administrator:schoolZ']

The dynacl module "rolecmp" allows ACLs like this:

attrs=krb5...,samba...,userPassword,pw...
  by dynacl/rolecmp/teacher,schooladmin=student write
  by dynacl/rolecmp/schooladmin=teacher write

The dynacl module does implicitly compare the school part (behind the
colon) of the "role" attribute of both the accessing and the accessed
object. The accessing objects roles are all of those on the left side of
the equality sign. The accessed objects role is on the right side.

In the above ACL, access would be allowed for example:
* by a user with ['teacher:X', 'student:Y'] to a user with ['student:X',
'administrator:Z'], because 'teacher:X' and 'student:X' match.
* by a user with ['teacher:Z', 'schooladmin:Y'] to a user with
['student:X', 'teacher:Y'], because 'schooladmin:Y' and 'teacher:Y' match.

Access would be denied for example:
* by ['teacher:X', 'student:Y'] to ['student:Y']
* by ['schooladmin:X'] to ['student:Y', 'teacher:Z']

While the connection does not change from user to role, the
authorization process decides only by compare roles (at places)... this
can still be called role based authorization, right?

We like his PoC a lot:
* It is very easy to read (esp. compared with sets).
* It is easy to extend: we/our customers will be able to create new
roles without touching the dynacl module!
* In tests it was at least not slower than our current set-based ACLs.


Can you think of a conceptual or technical problem with this solution?


Greetings
Daniel

PS: as a bonus, this will allow 3rd parties to do queries like this:
* Is user 'uid=foo' a student (anywhere)? -->
'(&(uid=foo)(role=student:*))'.
* Is user 'uid=bar' a teacher at school "X"? -->
'(&(uid=bar)(role=teacher:X))'.

We'll also need a role:school definition like 'administrator:*' to
express "is an administrator in all schools". Not sure about using the
asterisk here though...


-- 
Daniel Tröder
Open Source Software Engineer
http://www.univention.de

[no subject]

[Chris Cardone]

Hello All!

I have started building a large scale OpenLDAP infrastructure for the
company I work for and Im running into one issue i cant seem to resolve.

The final architecture is 4 Master servers (each one in its own data center
across the USA)
We also want to have 2 slaves tied to each master.  We deal with an
incredibly high amount of authentication traffic.

I currently have the 4 masters configured (n-master - using syncrepl) that
is functioning as designed, cn=config and user databases are successfully
replicated across the 4 servers no matter which server you use to update.

What I am having issues with is getting the slaves to sync to the masters.

I have the rpuser set up, the machines can talk to each other. I can run
queries using the rpuser from any slave to any master and get data back.  I
can see the rpuser connecting to the master, and showing successful
authentication in an attempt to replicate back to the slave.

But this error comes up
 do_syncrep2: rid=010 got search entry without Sync State control

and user data is not replicated back to the slave.

some additional notes:
On the slaves, i did NOT replicate the cn=config db {0) only the

here is the LDIF file (with hostnames/passwd removed)

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=010
  provider=ldap://master-1.example.com:389/
  bindmethod=simple
  binddn="uid=rpuser,dc=example,dc=com"
  credentials=banana
  searchbase="dc=example,dc=com"
  type=refreshAndPersist
  retry="30 5 300 3"
  interval=00:00:05:00

here is the applied config on the slave server

# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=squaretrade,dc=com
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=example,dc=com
olcSyncrepl: {0}rid=010 provider=ldap://master-1.example.com
 :389/ bindmethod=simple binddn="uid=rpuser,dc=example,dc=com" credentials
 =banana searchbase="dc=example,dc=com" type=refreshAndPersist retry="30 5
  300 3" interval=00:00:05:00
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824


here is the syncprov config on the master it is communicating with

# {0}syncprov, {1}mdb, config
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov


My questions
1> does the slave also require the cn=config database replication?
2> do the masters need similar configs (i.e. like the n-master config) does
RID=010 also need to be configured on the master?


here is a section of logs from a sync attempt

Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: =>do_syncrepl rid=010
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: =>do_syncrep2 rid=010
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: do_syncrep2: rid=010
got search entry without Sync State control (dc=example,dc=com)
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: do_syncrepl: rid=010 rc
-1 retrying (1 retries left)
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: activity on 1
descriptor
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: activity on:
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]:
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
Apr 18 09:27:36 la1-ldap-slave-prod-1 slapd[14543]: daemon: epoll:
listen=13 active_threads=0 tvp=zero




any assistance would be greatly appreciated!
and if there is additional information that will help just ask!

Christopher

Re: slapadd not adding some of the roleoccupent entries

[Quanah Gibson-Mount]

--On Tuesday, April 24, 2018 1:05 PM -0700 rammohan ganapavarapu 
 wrote:




Thank you for clarification, is it possible to share what are the missing
attributes? 


There are a number of them (such as entryUUID, entryCSN, etc).  Regardless, 
for replication to work, the operational attr values must be the same 
across servers.  This is generally why if you're bringing up replication in 
an environment where you already have an existing DB, you slapcat the DB 
off your "golden" master, and then use slapadd to import it to the other 
servers.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: role based authorization -> dynacl module?

[Shawn McKinney]

> On Apr 24, 2018, at 10:28 AM, Michael Ströder  wrote:
> 
> Ah, forgot to make that more clear (and people tend to miss that point):
> 
> Æ-DIR's ACLs are _static_ and work their way through the actual data
> which is changed to alter the effective access rights.

+1 to static ACL’s to guard the directory and storing the access lists as data 
instead.  

Re: Migration Task from 2.3.x to 2.4.x

[Quanah Gibson-Mount]

--On Friday, April 06, 2018 2:24 PM -0700 Periko Support 
 wrote:




This is correct guys or I miss something?


I think you're missing some on configuration.  It is likely that your 2.3 
server used "slapd.conf" for its configuration.  You will want to start 
with that file under the new 2.4 install, and then modify it as necessary. 
I.e., 2.4 has some changes to ACL processing, as documented under 



Once you have your slapd.conf updated to work with 2.4, then you can 
optionally choose to convert it to the dynamic configuration backend 
(cn=config) via slapadd.


Regards,
Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: removing ppolicy overlay

[Quanah Gibson-Mount]

--On Thursday, April 19, 2018 1:12 PM + Frank Swasey 
 wrote:



edit the slapd.conf file (if you are using slapd.d you are on your own)


It's not that different for slapd.d.  You'd want to slapcat it, remove the 
ppolicy overlay bits, and slapadd it back in. ;)


--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: slapadd not adding some of the roleoccupent entries

[Quanah Gibson-Mount]

--On Wednesday, April 11, 2018 1:31 PM -0700 rammohan ganapavarapu 
 wrote:




for the same scenario where i have a old server with data and trying to
replicate that data to new server with default skeleton created as below.


This will not work, because your skeleton is missing the required 
operational attrs.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: role based authorization -> dynacl module?

[Michael Ströder]

Michael Ströder wrote:
> For the use-cases affecting LDAP access (data maintenance, data
> retrieval) set-based ACLs are in effect which are indeed very slow.

Ah, forgot to make that more clear (and people tend to miss that point):

Æ-DIR's ACLs are _static_ and work their way through the actual data
which is changed to alter the effective access rights.

Ciao, Michael.

Re: role based authorization -> dynacl module?

[Michael Ströder]

TL;DR: When modeling roles one should start from the use-cases.

Howard Chu wrote:
> Most people miss the
> difference between roles and groups - group membership applies all the
> time. Once you're a member of a group, the privileges of that group are
> omnipresent.
> 
> Whereas, membership in a role grants you these privileges *only for as
> long as you assert that role* and adopting a role is a temporary,
> bounded activity.

Hmm, probably we mean the same. But I'd like to re-phrase a bit:

Each use-case (the actual work to be done) defines which actor roles are
allowed to exercise the use-case. The role can be determined in the
simplest case just by simple group membership (e.g. super-power admin
role) or by an arbitrary set of (dynamic) conditions.

In Æ-DIR the roles are mainly driven by use-cases and are always limited
to a certain "scope", e.g. by relationship of objects to the zone(s) or
by service group(s). [1]

For the use-cases affecting LDAP access (data maintenance, data
retrieval) set-based ACLs are in effect which are indeed very slow.
So a dynacl module would be nice for that. Or a custom LDAP server...

> So you need, at the least, in an LDAP context, an exop that says "assume
> role X" and the corresponding "drop role X". Without these two
> primitives, you don't actually have roles or role-based access control.
> LDAP's spec for proxy authorization might be sufficient for this purpose.

I'd argue that for security reasons the change-role / change-hat action
should never be possible without a (re-)authentication. So in Æ-DIR true
role separation simply requires a separate user/system account.
But that's me.

Ciao, Michael.

[1] https://www.ae-dir.com/docs.html#roles



smime.p7s
Description: S/MIME Cryptographic Signature

Re: role based authorization -> dynacl module?

[Michael Ströder]

Shawn McKinney wrote:
> Why use ACL’s for fine-grained authZ?  
> 
> It’s drawbacks, 
> - Not standard / LDAPv3 server lock-in (might not be a problem for you)
> - difficult to maintain and test (complex)

You have both of these issues for every non-trivial access control
system. Especially you need automated tests.

> To determine if necessary another question - how are your
> applications interacting with the directory.  Are they connecting
> using LDAPv3 operations (like search and bind), or is there are
> higher level abstraction in place, (like mod_authnz_ldap)?

That's the real question: Does the end-user ever impersonate directly on
the LDAP connection (optionally via a web application).

Ciao, Michael.

Re: role based authorization -> dynacl module?

[Shawn McKinney]

> On Apr 20, 2018, at 6:45 AM, Daniel Tröder  wrote:
> 
> I am in the process of implementing a role concept via ACLs and hope for
> a hint so that I don't invent the wheel a second time.
> 

I applaud your decision to not reinvent the wheel but have doubts about using 
ACL’s to accomplish (more later)

> 
> On Apr 20, 2018, at 6:45 AM, Daniel Tröder  wrote:
> 
> Specifically, it is about identity management for schools. A user
> (object) can have several roles in multiple schools. Permissions on
> other LDAP objects can thus differ depending on the role(s) the user and
> the object have in the same school(s).
> 

Classic RBAC scenario for sure.  Nice job using a standards-based approach btw.

> 
> On Apr 20, 2018, at 6:45 AM, Daniel Tröder  wrote:
> 
> For example, a user could have been assigned the following roles that
> are scattered over several schools:
> → "Teacher" in school 1
> → "School admin" in school 2
> → "Parent" in school 3
> → both "Teacher" and "Staff" in school 4
> 
> ACLs should now be defined accordingly, e.g.
> → the role "teacher" at school X can reset the password for the role
> "student" at school X
> → the role "teacher" at school X *cannot* reset the password for the
> role "student" of school Y
> → the role "school administrator" at school X can reset the password for
> the roles "student" and "teacher" at school X
> → ...

Why use ACL’s for fine-grained authZ?  

It’s drawbacks, 
- Not standard / LDAPv3 server lock-in (might not be a problem for you)  
- difficult to maintain and test (complex)

To determine if necessary another question - how are your applications 
interacting with the directory.  Are they connecting using LDAPv3 operations 
(like search and bind), or is there are higher level abstraction in place, 
(like mod_authnz_ldap)?

> 
> On Apr 20, 2018, at 6:45 AM, Daniel Tröder  wrote:
> 
> So far I have not seen any way to map such a construct via groups or
> sets without including a separate ACL for each group, which is a
> performance issue.
> Is there another way to map the role concept besides implementing an own
> dynacl module?

There are many ways to achieve RBAC using LDAP.  Typically these other methods 
will use a library that gets imbedded into your application to use for the 
security checks. That way the directory ACL’s remain simple, and the bits 
corresponding to the policy live inside of objects that are stored within it, 
not in metadata for its config.  

Disclaimer, I’m a PMC here:
http://directory.apache.org/fortress/

— Shawn