You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Shawn McKinney <sm...@symas.com> on 2016/08/01 21:21:47 UTC
New LDAP Realm Proposal
Hello,
I am thinking about creating a new LDAP realm for Shiro that has the following features:
1. usage of Apache LDAP API (rather than JNDI)
2. capability to perform permission based checks
3. capability for role based checks
4. declarative syntax for mapping to a variety of LDAP schemas
5. compatibility with any LDAPv3 impls including OpenLDAP, Apache Directory Server, ActiveDirectory, etc
But before I get started I wanted to gauge interest from the Shiro user community. If the idea takes hold, I will likely create under my github account, and if all goes well, will contribute back to this community.
The value proposition is to have a fully functioning LDAP realm available for those in need.
WDYT?
Shawn
Re: New LDAP Realm Proposal
Posted by Shawn McKinney <sm...@symas.com>.
> On Sep 28, 2016, at 7:22 PM, opticyclic <op...@gmail.com> wrote:
>
> If you post your fork where you are doing the work, I can pitch in a bit.
>
Actually I’m counting on the other way around. My inclination is to write the data access layer and let someone who is knowledgable of shiro’s framework do the rest. Which is to say I can’t spare the time to develop expertise in how shiro works, but I can help where my skills are, java, ldap, rbac, to add permissions.
Shawn
Re: New LDAP Realm Proposal
Posted by opticyclic <op...@gmail.com>.
If you post your fork where you are doing the work, I can pitch in a bit.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581301.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: New LDAP Realm Proposal
Posted by Shawn McKinney <sm...@symas.com>.
I wanted to wait a bit to gauge community interest on this before spending a bunch of time on it. It appears that it is there. The other constraint is time, as in not enough of it. I’d be open to a combined effort to speed thing up.
> On Sep 26, 2016, at 9:20 AM, Brian Demers <br...@gmail.com> wrote:
>
> I'm all for a improved LDAP realm. The points in the stackoverflow posts are also valid.
>
> Sonatype's Nexus did something similar with their LDAP realm. We had templates for common schemas and usage patterns, authentication only, AD, Posix with dynamic or without static groups, etc.
> https://books.sonatype.com/nexus-book/reference/ldap-sect-user-group-mapping.html
>
> NOTE: The Nexus solution used an API that also supported writes, so something done in Shiro would not need to be as involved (I would guess)
>
>
> If anyone wants to take this on send us a pull request!
> -Brian
>
> On Sun, Sep 25, 2016 at 7:55 PM, opticyclic <op...@gmail.com> wrote:
> I think once #3 and #4 are done then #5 almost comes automatically as the
> user can add the various filters in the ini for the different uses cases.
> However, there should be a useful set of defaults that work most of the
> time.
> In that case, #5 could be implemented as a series of default search filters
> or one big search filter that included lots of OR statements to account for
> searching for all the common use cases.
>
> I am for this new realm and I already posted on stackoverflow before seeing
> this thread
> http://stackoverflow.com/questions/39679428/is-there-a-generic-way-to-search-for-ldap-groups-with-shiro
>
> As you can see, I was disappointed to not find #3, 4, 5 already included in
> DefaultLdapRealm.
>
> With that in mind, could you do it so that 3,4,5 are done in
> DefaultLdapRealm and then extend it to add #1 in the subclass?
>
> That way most of the features are available by default and the subclass is
> an optional alternative that uses the Apache LDAP API instead of JNDI.
>
> I haven't mentioned #2 as I'm not sure if that depends on the API or can be
> done with JNDI too.
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581291.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: New LDAP Realm Proposal
Posted by Brian Demers <br...@gmail.com>.
I'm all for a improved LDAP realm. The points in the stackoverflow posts
are also valid.
Sonatype's Nexus did something similar with their LDAP realm. We had
templates for common schemas and usage patterns, authentication only, AD,
Posix with dynamic or without static groups, etc.
https://books.sonatype.com/nexus-book/reference/ldap-sect-user-group-mapping.html
NOTE: The Nexus solution used an API that also supported writes, so
something done in Shiro would not need to be as involved (I would guess)
If anyone wants to take this on send us a pull request!
-Brian
On Sun, Sep 25, 2016 at 7:55 PM, opticyclic <op...@gmail.com> wrote:
> I think once #3 and #4 are done then #5 almost comes automatically as the
> user can add the various filters in the ini for the different uses cases.
> However, there should be a useful set of defaults that work most of the
> time.
> In that case, #5 could be implemented as a series of default search filters
> or one big search filter that included lots of OR statements to account for
> searching for all the common use cases.
>
> I am for this new realm and I already posted on stackoverflow before seeing
> this thread
> http://stackoverflow.com/questions/39679428/is-there-a-
> generic-way-to-search-for-ldap-groups-with-shiro
>
> As you can see, I was disappointed to not find #3, 4, 5 already included in
> DefaultLdapRealm.
>
> With that in mind, could you do it so that 3,4,5 are done in
> DefaultLdapRealm and then extend it to add #1 in the subclass?
>
> That way most of the features are available by default and the subclass is
> an optional alternative that uses the Apache LDAP API instead of JNDI.
>
> I haven't mentioned #2 as I'm not sure if that depends on the API or can be
> done with JNDI too.
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.
> nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581291.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: New LDAP Realm Proposal
Posted by opticyclic <op...@gmail.com>.
I think once #3 and #4 are done then #5 almost comes automatically as the
user can add the various filters in the ini for the different uses cases.
However, there should be a useful set of defaults that work most of the
time.
In that case, #5 could be implemented as a series of default search filters
or one big search filter that included lots of OR statements to account for
searching for all the common use cases.
I am for this new realm and I already posted on stackoverflow before seeing
this thread
http://stackoverflow.com/questions/39679428/is-there-a-generic-way-to-search-for-ldap-groups-with-shiro
As you can see, I was disappointed to not find #3, 4, 5 already included in
DefaultLdapRealm.
With that in mind, could you do it so that 3,4,5 are done in
DefaultLdapRealm and then extend it to add #1 in the subclass?
That way most of the features are available by default and the subclass is
an optional alternative that uses the Apache LDAP API instead of JNDI.
I haven't mentioned #2 as I'm not sure if that depends on the API or can be
done with JNDI too.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581291.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: New LDAP Realm Proposal
Posted by Pierre Smits <pi...@gmail.com>.
That's a great initiative, Shawn.
Best regards,
Pierre
Op dinsdag 2 augustus 2016 heeft Shawn McKinney <sm...@symas.com> het
volgende geschreven:
>
> > On Aug 2, 2016, at 9:04 AM, Brian Demers <brian.demers@gmail.com
> <javascript:;>> wrote:
> >
> > That is really cool, I'll have to take a closer look at fortress and it
> looks like Apache Directory is picking up steam again (Apache DS was a
> great tool, i'm looking forward to the updates)
> >
>
> Yes the project has added many committers of late, along with new
> sub-projects like fortress (access management), kerby (kerberos
> implementation), and a SCIM component contributed by Penn State.
> Eventually apacheds will be fitted with a new backend (mavibot), which will
> improve stability and performance.
>
> >
> > On Aug 2, 2016, at 9:04 AM, Brian Demers <brian.demers@gmail.com
> <javascript:;>> wrote:
> >
> > One caution I have about this is, I'm not sure what percentage of users
> will have the ability to update their LDAP servers (in or outside an
> application). So in my opinion anything requiring the 'ft' ObjectClasses
> would have to be optional.
> >
>
> Good to know. Ideally, the object class and attribute mappings are
> defined in shiro’s config file, enabling different object classes to be
> used. It remains to be seen how practical that idea is. i.e. there’s more
> to permission data structure usage than schema definitions. In any case
> the ability to map to a variety of structures would be a work-in-progress.
> The apache ldap api has capabilities here that may be useful. I’ll start
> with the fortress model and go from there.
>
> Shawn
>
>
--
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: New LDAP Realm Proposal
Posted by Shawn McKinney <sm...@symas.com>.
> On Aug 2, 2016, at 9:04 AM, Brian Demers <br...@gmail.com> wrote:
>
> That is really cool, I'll have to take a closer look at fortress and it looks like Apache Directory is picking up steam again (Apache DS was a great tool, i'm looking forward to the updates)
>
Yes the project has added many committers of late, along with new sub-projects like fortress (access management), kerby (kerberos implementation), and a SCIM component contributed by Penn State. Eventually apacheds will be fitted with a new backend (mavibot), which will improve stability and performance.
>
> On Aug 2, 2016, at 9:04 AM, Brian Demers <br...@gmail.com> wrote:
>
> One caution I have about this is, I'm not sure what percentage of users will have the ability to update their LDAP servers (in or outside an application). So in my opinion anything requiring the 'ft' ObjectClasses would have to be optional.
>
Good to know. Ideally, the object class and attribute mappings are defined in shiro’s config file, enabling different object classes to be used. It remains to be seen how practical that idea is. i.e. there’s more to permission data structure usage than schema definitions. In any case the ability to map to a variety of structures would be a work-in-progress. The apache ldap api has capabilities here that may be useful. I’ll start with the fortress model and go from there.
Shawn
Re: New LDAP Realm Proposal
Posted by Brian Demers <br...@gmail.com>.
That is really cool, I'll have to take a closer look at fortress and it
looks like Apache Directory is picking up steam again (Apache DS was a
great tool, i'm looking forward to the updates)
One caution I have about this is, I'm not sure what percentage of users
will have the ability to update their LDAP servers (in or outside an
application). So in my opinion anything requiring the 'ft' ObjectClasses
would have to be optional.
Keep us posted,
-Brian
On Tue, Aug 2, 2016 at 8:54 AM, Shawn McKinney <sm...@symas.com> wrote:
>
> >
> > On Aug 1, 2016, at 5:19 PM, Brian Demers <br...@gmail.com> wrote:
> >
> > I did something similar with Sonatype's Nexus a while back, the code has
> moved around a bit since then, but you can still fine it:
> https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-ldap-common/src/main/java/org/sonatype/security/ldap/realms/AbstractLdapAuthenticationRealm.java
> > NOTE: this code is EPL
>
> Thanks, I’ll have a look.
>
> >
> > On Aug 1, 2016, at 5:19 PM, Brian Demers <br...@gmail.com> wrote:
> >
> > How are you planning on storing/querying permission ?
>
> Follow apache fortress' model. It defines a data structure mapping of
> object->operation as a hierarchy with one-to-many relationship between them.
>
> http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/model/Permission.html
>
> Here is schema for the two elements, permission object and operation:
>
> ## Fortress Permission Object Structural Object Class
> objectclass ( ftObId:2
> NAME 'ftObject'
> DESC 'Fortress Permission Object Class'
> SUP organizationalunit
> STRUCTURAL
> MUST (
> ftId $
> ftObjNm
> )
> MAY (
> ftType
> )
> )
>
> ## Fortress Permission Operation Structural Object Class
> objectclass ( ftObId:3
> NAME 'ftOperation'
> DESC 'Fortress Permission Operation Structural Object Class'
> SUP organizationalrole
> STRUCTURAL
> MUST (
> ftId $
> ftPermName $
> ftObjNm $
> ftOpNm
> )
> MAY (
> ftObjId $
> ftRoles $
> ftUsers $
> ftType
> )
> )
>
> Below is example idif extract for:
> object name: com.mycompany.Page1
> op name: add
> object ids, 123, 456, 789
>
> The advantage is simplicity and performance. In order to perform a single
> permission check, i.e. checkAccess, it requires a single ldap ‘read’
> operations. To retrieve all permissions for a user, i.e.
> sessionPermissions, is done with a single ldap ‘search’ operation.
>
> The disadvantage is currently doesn’t support for wildcard definitions in
> operation name. I’ll need to study the shiro model a bit more before I
> claim that it can be added to this model.
>
> dn: ftOpNm=Update, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=RBAC,
> dc=e
> xample,dc=com
> ftPermName: com.mycompany.Page1.Update
> ftObjNm: com.mycompany.Page1
> ftOpNm: Update
> ftRoles: PAGE1_123
> ftRoles: PAGE1_456
> ftRoles: PAGE1_789
> ftRoles: ROLE_DEMO2_SUPER_USER
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> description: Permission for page1.update
> cn: com.mycompany.Page1.Update
> ftId: b9672dea-9091-4634-a739-1382f604ad40
>
> dn: ftObjId=123+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
> BAC, dc=example,dc=com
> ftRoles: PAGE1_123
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: f27f6094-55ac-47a5-9977-0aa315a68520
> cn: com.mycompany.Page1.Add
> ftObjId: 123
> description: Permission for page1.add on Customer record 123
>
> dn: ftObjId=456+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
> BAC, dc=example,dc=com
> ftRoles: PAGE1_456
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: 9e2a5ea1-330d-4883-8113-3008e7a12858
> cn: com.mycompany.Page1.Add
> ftObjId: 456
> description: Permission for page1.add on Customer record 456
>
> dn: ftObjId=789+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
> BAC, dc=example,dc=com
> ftRoles: PAGE1_789
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: 6fa2cab8-f83b-4efa-bd6b-f9de5a7bb871
> cn: com.mycompany.Page1.Add
> ftObjId: 789
> description: Permission for page1.add on Customer record 789
>
>
>
Re: New LDAP Realm Proposal
Posted by Shawn McKinney <sm...@symas.com>.
>
> On Aug 1, 2016, at 5:19 PM, Brian Demers <br...@gmail.com> wrote:
>
> I did something similar with Sonatype's Nexus a while back, the code has moved around a bit since then, but you can still fine it: https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-ldap-common/src/main/java/org/sonatype/security/ldap/realms/AbstractLdapAuthenticationRealm.java
> NOTE: this code is EPL
Thanks, I’ll have a look.
>
> On Aug 1, 2016, at 5:19 PM, Brian Demers <br...@gmail.com> wrote:
>
> How are you planning on storing/querying permission ?
Follow apache fortress' model. It defines a data structure mapping of object->operation as a hierarchy with one-to-many relationship between them.
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/model/Permission.html
Here is schema for the two elements, permission object and operation:
## Fortress Permission Object Structural Object Class
objectclass ( ftObId:2
NAME 'ftObject'
DESC 'Fortress Permission Object Class'
SUP organizationalunit
STRUCTURAL
MUST (
ftId $
ftObjNm
)
MAY (
ftType
)
)
## Fortress Permission Operation Structural Object Class
objectclass ( ftObId:3
NAME 'ftOperation'
DESC 'Fortress Permission Operation Structural Object Class'
SUP organizationalrole
STRUCTURAL
MUST (
ftId $
ftPermName $
ftObjNm $
ftOpNm
)
MAY (
ftObjId $
ftRoles $
ftUsers $
ftType
)
)
Below is example idif extract for:
object name: com.mycompany.Page1
op name: add
object ids, 123, 456, 789
The advantage is simplicity and performance. In order to perform a single permission check, i.e. checkAccess, it requires a single ldap ‘read’ operations. To retrieve all permissions for a user, i.e. sessionPermissions, is done with a single ldap ‘search’ operation.
The disadvantage is currently doesn’t support for wildcard definitions in operation name. I’ll need to study the shiro model a bit more before I claim that it can be added to this model.
dn: ftOpNm=Update, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=RBAC, dc=e
xample,dc=com
ftPermName: com.mycompany.Page1.Update
ftObjNm: com.mycompany.Page1
ftOpNm: Update
ftRoles: PAGE1_123
ftRoles: PAGE1_456
ftRoles: PAGE1_789
ftRoles: ROLE_DEMO2_SUPER_USER
objectClass: top
objectClass: organizationalRole
objectClass: ftOperation
objectClass: ftProperties
objectClass: ftMods
description: Permission for page1.update
cn: com.mycompany.Page1.Update
ftId: b9672dea-9091-4634-a739-1382f604ad40
dn: ftObjId=123+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=R
BAC, dc=example,dc=com
ftRoles: PAGE1_123
ftRoles: ROLE_DEMO2_SUPER_USER
ftPermName: com.mycompany.Page1.Add
objectClass: top
objectClass: organizationalRole
objectClass: ftOperation
objectClass: ftProperties
objectClass: ftMods
ftOpNm: Add
ftObjNm: com.mycompany.Page1
ftId: f27f6094-55ac-47a5-9977-0aa315a68520
cn: com.mycompany.Page1.Add
ftObjId: 123
description: Permission for page1.add on Customer record 123
dn: ftObjId=456+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=R
BAC, dc=example,dc=com
ftRoles: PAGE1_456
ftRoles: ROLE_DEMO2_SUPER_USER
ftPermName: com.mycompany.Page1.Add
objectClass: top
objectClass: organizationalRole
objectClass: ftOperation
objectClass: ftProperties
objectClass: ftMods
ftOpNm: Add
ftObjNm: com.mycompany.Page1
ftId: 9e2a5ea1-330d-4883-8113-3008e7a12858
cn: com.mycompany.Page1.Add
ftObjId: 456
description: Permission for page1.add on Customer record 456
dn: ftObjId=789+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=R
BAC, dc=example,dc=com
ftRoles: PAGE1_789
ftRoles: ROLE_DEMO2_SUPER_USER
ftPermName: com.mycompany.Page1.Add
objectClass: top
objectClass: organizationalRole
objectClass: ftOperation
objectClass: ftProperties
objectClass: ftMods
ftOpNm: Add
ftObjNm: com.mycompany.Page1
ftId: 6fa2cab8-f83b-4efa-bd6b-f9de5a7bb871
cn: com.mycompany.Page1.Add
ftObjId: 789
description: Permission for page1.add on Customer record 789
Re: New LDAP Realm Proposal
Posted by Brian Demers <br...@gmail.com>.
I'm interested in a few of these, specifically #4, as I've seen a my share
of users struggle to configure LDAP, especially when venturing outside of
one of the more common schemas.
#3 naturally falls with #4
I did something similar with Sonatype's Nexus a while back, the code has
moved around a bit since then, but you can still fine it:
https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-ldap-common/src/main/java/org/sonatype/security/ldap/realms/AbstractLdapAuthenticationRealm.java
NOTE: this code is EPL
How are you planning on storing/querying permission ?
On Mon, Aug 1, 2016 at 5:34 PM, David Jencks <da...@yahoo.com> wrote:
> What is the “Apache LDAP API” you mention in (1)? Something you’re going
> to write for this realm or something that already exists somewhere else?
>
> thanks
> david jencks
>
> > On Aug 1, 2016, at 2:21 PM, Shawn McKinney <sm...@symas.com> wrote:
> >
> > Hello,
> >
> > I am thinking about creating a new LDAP realm for Shiro that has the
> following features:
> >
> > 1. usage of Apache LDAP API (rather than JNDI)
> > 2. capability to perform permission based checks
> > 3. capability for role based checks
> > 4. declarative syntax for mapping to a variety of LDAP schemas
> > 5. compatibility with any LDAPv3 impls including OpenLDAP, Apache
> Directory Server, ActiveDirectory, etc
> >
> > But before I get started I wanted to gauge interest from the Shiro user
> community. If the idea takes hold, I will likely create under my github
> account, and if all goes well, will contribute back to this community.
> >
> > The value proposition is to have a fully functioning LDAP realm
> available for those in need.
> >
> > WDYT?
> >
> > Shawn
>
>
Re: New LDAP Realm Proposal
Posted by Shawn McKinney <sm...@symas.com>.
> On Aug 1, 2016, at 4:34 PM, David Jencks <da...@yahoo.com> wrote:
>
> What is the “Apache LDAP API” you mention in (1)? Something you’re going to write for this realm or something that already exists somewhere else?
http://directory.apache.org/api/
Re: New LDAP Realm Proposal
Posted by David Jencks <da...@yahoo.com>.
What is the “Apache LDAP API” you mention in (1)? Something you’re going to write for this realm or something that already exists somewhere else?
thanks
david jencks
> On Aug 1, 2016, at 2:21 PM, Shawn McKinney <sm...@symas.com> wrote:
>
> Hello,
>
> I am thinking about creating a new LDAP realm for Shiro that has the following features:
>
> 1. usage of Apache LDAP API (rather than JNDI)
> 2. capability to perform permission based checks
> 3. capability for role based checks
> 4. declarative syntax for mapping to a variety of LDAP schemas
> 5. compatibility with any LDAPv3 impls including OpenLDAP, Apache Directory Server, ActiveDirectory, etc
>
> But before I get started I wanted to gauge interest from the Shiro user community. If the idea takes hold, I will likely create under my github account, and if all goes well, will contribute back to this community.
>
> The value proposition is to have a fully functioning LDAP realm available for those in need.
>
> WDYT?
>
> Shawn