openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 15 Aug '11

15 Aug '11

<html><body><div>Kurt, thanks for taking the time to look this over and allowing t= his to proceed.  We are looking forward to working with you and the ot= hers on this project in the near future.  This has been a long time co= ming for us and we appreciate this opportunity.</div><div> </div><div>He= re's the statement of origin. </div><div> </div><div>The product nam= ed "Fortress Core" includes contributions that were created by JoshuaTree S= oftware, LLC, who =0Ais the exclusive owner of the works.  This contri= bution is made =0Aavailable as indicated by the copyright and license state= ments attached to the the =0Awork.</div><div> </div><div></div><div>Shaw= n McKinney</div><blockquote id=3D"replyBlockquote" webmail=3D"1" style=3D"b= order-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:= 10pt; color: black; font-family: verdana;">=0A<div id=3D"wmQuoteWrapper">= =0A-------- Original Message -------- =0ASubject: Re: (ITS#6995) Request= for Contribution of Identity Access =0AManagement Software to OpenLDAP = Project =0AFrom: Kurt Zeilenga <<a href=3D"mailto:Kurt@OpenLDAP.org">= Kurt(a)OpenLDAP.org</a>> =0ADate: Mon, August 15, 2011 2:35 pm =0ATo= : <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.co= m</a> =0ACc: <a href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its@O= penLDAP.org</a> =0A =0AShawn, =0A =0AI have reviewed the submit= ted materials. =0A =0AOther than a lack of a statement of origin, I f= ind no reason why these materials cannot be accepted. Please submit a "sta= tement of origin" in a follow-up to this ITS. This can simply be a stateme= nt to the effect that the all the submitted materials were authored by Josh= uaTree Software, JoshaaTree is the exclusive owner of the works, and that t= he contribution is made available as indicated by the copyright and license= statements in the work. If the work includes materials derived from works= to which others own or otherwise have rights to, please detail. =0A = =0AThe Foundation has no objection to the Project establishing a sub-projec= t of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub proje= cts, to develop works based upon your contribution. It is the Foundation u= nderstanding that Project is also willing to establish such a sub-project, = and extend commit privs to the key developers who produced the contributed = work. =0A =0AIt is noted that the OpenLDAP Foundation, if it accepts = the final contribution, would from time to time publish works derived (such= as the source repository itself, and possibly packaged source bundles) fro= m your contribution as well as possibly the contributions of others. The O= penLDAP Foundation will license its copyright right interests (initially li= kely quite limited) using the OpenLDAP Public License, and will encourage c= ommunity members to license their contributions in a manner consistent with= our general contribution guidelines. The OpenLDAP Public License is compa= tible with the 'New BSD open source license' and similar in its basic terms= . =0A =0AThe initial COPYRIGHT file (upon acceptance and initial publ= ication by the OpenLDAP Foundation) would be based on the COPYRIGHT file cu= rrently found in OpenLDAP Software distributions, excepting JoshuaTree Soft= ware would be named as the contributor of the materials for which the publi= shed work is derived from, and notice immediately following the Foundation'= s notice would be that provided by JoshauTree covering the work as contribu= tions. =0A =0AIt is noted that I recently attempted to re-download th= e materials and they were no longer available. That fine, we'd want you to= upload fresh zips to our servers once we all were ready to proceed. =0A= =0ARegards, Kurt =0A =0AOn Jul 14, 2011, at 6:51 PM, <a href=3D"h= ttp://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.com</a> wrote:<b= r>=0A =0A> Full_Name: Shawn McKinney =0A> Version: All =0A&g= t; OS: All =0A> URL: ftp://<a href=3D"http://ftp.openldap.org/incomin= g">ftp.openldap.org/incoming</a>/ =0A> Submission from: (NULL) (99.34= .198.251) =0A> =0A> =0A> Hello, =0A> =0A> = We have created a new Identity and Access Management SDK, called Fortress, = that =0A> uses Java and OpenLDAP to provide authentication, RBAC, ARB= AC, password =0A> policies, auditing and more. =0A> =0A>= It has taken us 2.5 years of steady work to get it ready for this 1.0 rele= ase. =0A> This SDK has approximately 50K lines of Java code of which= approximately 25K are =0A> dedicated to testing using JUnit automate= d tests to ensure it works correctly. =0A> There are in excess of 10= 0 public APIs available for use. There is also a Java =0A> EE contai= ner plug-in that provides authentication and authorization services to = =0A> Websphere, Tomcat and JBoss app servers in a declarative fashion. = =0A> =0A> This product has not been published and we would li= ke to release it as one of =0A> the products under OpenLDAP family of= products. The product will be released =0A> under New BSD open sour= ce license (license information is contained in the =0A> source archi= ves on ftp server). =0A> =0A> I have uploaded seven packages t= o our FTP server that contain the source, =0A> documentation and othe= r items for you to look at. =0A> =0A> host: <a href=3D"http://= jtstools.com">jtstools.com</a> =0A> user: jtsguest1 =0A> pw: Op= enLd@p1 =0A> =0A> The packages are as follows: =0A> = =0A> Fortress Core SDK =0A> =0A> 1. source - fortressSrc-= 1.0.0-rc1.zip - 352K bytes =0A> 2. source - fortressTestSrc-1.0.0-r= c1.zip - 159K bytes =0A> 3. tutorial/doc - fortressSamples-1.0.0-rc= 1.zip - 766K bytes =0A> 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.= 4M bytes =0A> 5. ldap (folder) - Fortress schema and OpenLDAP slapd= .conf =0A> =0A> =0A> Fortress Realm (Java EE Container = plug-ins) =0A> =0A> 6. source - fortressRealmSrc-1.0.0-rc1.z= ip - 45K bytes =0A> 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 7= 6K bytes =0A> =0A> =0A> Package 4 contains complete jav= adoc for the APIs. =0A> =0A> In package 4, this link, ./fortr= essDoc-1.0.0-rc1/index.html, contains the =0A> overall summary of the= SDK. =0A> =0A> this link, ./oamCore/trunk/dist/docs/api/index= .html, contains package =0A> descriptions along with detailed documen= tation describing the contents of the =0A> SDK. =0A> =0A&gt= ; What we are requesting from the OpenLDAP foundation: =0A> =0A&g= t; 1. Source code repository to host the SDK and Realm packages. =0A>= 2. Bug tracking. =0A> 3. Developer and User forums. =0A> 4. Wi= ki (this is a nice to have) =0A> =0A> Our goal is to run the o= pen source project with your organization and cultivate =0A> a health= y developer and user community. We have high hopes for this product =0A= > (and OpenLDAP) and consider the 2 products together as an open source<= br>=0A> alternative for IAM products that will compete with the commerci= al vendor =0A> offerings. =0A> =0A> Once 1.0 is releas= ed, we will begin working on 2.0 which will include UI's to =0A> cont= rol Fortress and OpenLDAP along with a policy server to wrap the Fortress<b= r>=0A> Java APIs with HTTP/REST Web APIs to make it available to all pla= tforms. =0A> =0A> Thanks in advance for your consideration.<br= >=0A> =0A> Shawn McKinney =0A> JoshuaTree Software =0A&g= t; <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.c= om</a> =0A> =0A =0A=0A</div>=0A</blockquote></body></ht= ml>

1 0

Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠OpenLDAP.org 15 Aug '11

15 Aug '11

Shawn, I have reviewed the submitted materials. Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail. The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work. It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms. The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions. It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed. Regards, Kurt On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote: > Full_Name: Shawn McKinney > Version: All > OS: All > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.34.198.251) > > > Hello, > > We have created a new Identity and Access Management SDK, called Fortress, that > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password > policies, auditing and more. > > It has taken us 2.5 years of steady work to get it ready for this 1.0 release. > This SDK has approximately 50K lines of Java code of which approximately 25K are > dedicated to testing using JUnit automated tests to ensure it works correctly. > There are in excess of 100 public APIs available for use. There is also a Java > EE container plug-in that provides authentication and authorization services to > Websphere, Tomcat and JBoss app servers in a declarative fashion. > > This product has not been published and we would like to release it as one of > the products under OpenLDAP family of products. The product will be released > under New BSD open source license (license information is contained in the > source archives on ftp server). > > I have uploaded seven packages to our FTP server that contain the source, > documentation and other items for you to look at. > > host: jtstools.com > user: jtsguest1 > pw: OpenLd@p1 > > The packages are as follows: > > Fortress Core SDK > > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf > > > Fortress Realm (Java EE Container plug-ins) > > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes > > > Package 4 contains complete javadoc for the APIs. > > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the > overall summary of the SDK. > > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package > descriptions along with detailed documentation describing the contents of the > SDK. > > What we are requesting from the OpenLDAP foundation: > > 1. Source code repository to host the SDK and Realm packages. > 2. Bug tracking. > 3. Developer and User forums. > 4. Wiki (this is a nice to have) > > Our goal is to run the open source project with your organization and cultivate > a healthy developer and user community. We have high hopes for this product > (and OpenLDAP) and consider the 2 products together as an open source > alternative for IAM products that will compete with the commercial vendor > offerings. > > Once 1.0 is released, we will begin working on 2.0 which will include UI's to > control Fortress and OpenLDAP along with a policy server to wrap the Fortress > Java APIs with HTTP/REST Web APIs to make it available to all platforms. > > Thanks in advance for your consideration. > > Shawn McKinney > JoshuaTree Software > shawn.mckinney(a)jtstools.com >

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by masarati＠aero.polimi.it 15 Aug '11

15 Aug '11

> michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if >> there's an >> accesslog DB configured at the provider. IMO this does not make sense >> since the >> accesslog DB is not replicated and one might not want to load >> slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers >> the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be > filtering > out DSA-specific opattrs at the consumer side. Agree. User-wise, there could be a (set of) configuration option(s) that result in a safe default filtering, while allowing "expert" users (or for experimental reasons) to replicate things arbitrarily. Alternatives: 1) protect auditContext with ACLs at the producer's side 2) document the need to use filter="(!(objectClass=auditContext))" (or whatever is appropriate) when configuring the consumer. p.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if there's an >> accesslog DB configured at the provider. IMO this does not make sense since the >> accesslog DB is not replicated and one might not want to load slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be filtering > out DSA-specific opattrs at the consumer side. > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs on the provider side, when the Syncrepl control is present. Something else is going on here, but since you failed to provide any config info there's no way to tell where the problem is. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if there's an > accesslog DB configured at the provider. IMO this does not make sense since the > accesslog DB is not replicated and one might not want to load slapo-accesslog > module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers the > auditContext contains two values for auditContext and even the same one. Since a syncrepl operation is a regular LDAP search, the provider sends everything that matches the search request. Probably we should be filtering out DSA-specific opattrs at the consumer side. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 9:03 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> Delta-Syncrepl (normal and MMR modes) both use an accesslog database. >> So your contention that accesslog DBs are not replicated is somewhat >> incorrect. > > Up to now I thought that the accesslog DB itself is only accessible at the > provider and not replicated to the consumer. At least that's what's IMO > written in the OpenLDAP Admin Guide: I just wanted to be clear that accesslog can be used for replication. Thank you for providing such a nice test case example. ;) As for delta-syncrepl MMR, it exists, its in HEAD, and I have it working with RE24 just fine. It may well go into the next 2.4 release, so don't ignore it. ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

quanah(a)zimbra.com wrote: > Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So > your contention that accesslog DBs are not replicated is somewhat incorrect. Up to now I thought that the accesslog DB itself is only accessible at the provider and not replicated to the consumer. At least that's what's IMO written in the OpenLDAP Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl "Delta-syncrepl works by maintaining a changelog of a selectable depth on the provider." Also in the Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl There's no accesslog database at the consumer (replica) configured. Delta-syncrepl in MMR mode is not finished yet, therefore I ignore this case for now. Because you are nitpicking in my case I set up a testbed. The accesslog DB itself is *not* replicated. Anyway the main issue here is that I regard replicating the attribute auditContext as not appropriate since you cannot access the referenced accesslog DB at the consumer. And it seems that with delta syncrepl the attribute is not replicated. But it seems to be replicated in a MMR setup with separate accesslog DBs configured at both providers. And this leads to this multiple but same(!) attribute values. We have four databases in our MMR test setup: cn=wsvdir-accesslog-de (for c=DE) cn=wsvdir-accesslog-system (for o=SYSTEM) o=SYSTEM (replicated in MMR setup) c=DE (replicated in MMR setup) In both providers I have dn: o=SYSTEM auditContext: cn=wsvdir-accesslog-system auditContext: cn=wsvdir-accesslog-system It does not happen in c=DE though. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 2:42 PM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if > there's an accesslog DB configured at the provider. IMO this does not > make sense since the accesslog DB is not replicated and one might not > want to load slapo-accesslog module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers > the auditContext contains two values for auditContext and even the same > one. Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So your contention that accesslog DBs are not replicated is somewhat incorrect. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

Full_Name: Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.26.156) It seems that attribute auditContext is replicated to consumers if there's an accesslog DB configured at the provider. IMO this does not make sense since the accesslog DB is not replicated and one might not want to load slapo-accesslog module at all in the consumer's config. In a 2-way MMR setup with accesslog DB attached to both master providers the auditContext contains two values for auditContext and even the same one.

1 0

(ITS#7018) unique URI's host part must be empty
by masarati＠aero.polimi.it 13 Aug '11

13 Aug '11

Full_Name: Pierangelo Masarati Version: master,re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.144.24.27) Submitted by: ando If empty "host" part is checked, misconfigurations like in <http://www.openldap.org/lists/openldap-technical/201108/msg00116.html> would be easily detected. A fix is coming. p.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs