subject:"Custom object classes and attributes"

> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny  wrote:
> 
> One option would be to let the developper to decide which STRUCTURAL
> class should be the root of the Users Entries, but that does not fit
> well with Fortress, because te 'cn' and 'sn' attributes are mandatory in
> te InetOgPerson ObjectClass. Moreover, Fortress is expecing may of the
> InetOrgPerson attributeType to be present...

Not exactly.  Yes, we use inetorgperson as a structural oc, but the only 
required attributes are uid and ou.  All others are optional from the caller’s 
perspective.

Cn and sn will use the value of uid if not otherwise set by caller:

final class UserDAO extends LdapDataProvider
{
 ...
  User create( User entity ) throws CreateException
{
  ...
// CN is required on inetOrgPerson object class, if caller did not 
set, use the userId:
if ( StringUtils.isEmpty( entity.getCn() ) )
{
entity.setCn( entity.getUserId() );
}

// SN is required on inetOrgPerson object class, if caller did not 
set, use the userId:
if ( StringUtils.isEmpty( entity.getSn() ) )
{
entity.setSn( entity.getUserId() );
}

> 
> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny  wrote:
> 
> The idea would be for Fortress to still let the user select which
> STRUCTURAL ObjectClass to use, and to default to a specific FortressUser
> STRUCTURAL ObjectClass, taht would mimic InetOrgPerson (but wth no
> mandatory attributeTypes). All teh needed attributes will be defined
> into AUXILLIARY ObjectClasses (including cn and sn).
> 
> Fro teh API point of view, thsi is easy, and it will just require a
> configuration: the STRUCTURAL to use.
> 

I’m not opposed to this idea but it will be a lot of work and has potential to 
make fortress complicated and brittle.  Speaking of, that would be my design 
criteria, if it increases either by much, I will not be in favor.

Inetorgperson is far from perfect but it is the closest thing we have to a 
standard entity model for user in the computing world.  The SCIM standard is 
largely based off of it.  Speaking of, where does it fit in this discussion?

> 
> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny  wrote:
> 
> 
> From Commander POV (the UI), that is a different story. The point being
> that it's impossible to anticipate all the possible needs for all the
> possible application out there. One solution would be to expose the User
> using a tabular representation, regardless of the attribute content and
> order (that means we lose all teh semantic). Anothe roption, way more
> complex, would be to define templates that will be specific : they will
> tell teh GUI what and how to expose the data. This is definitively be a
> very complex change in Commander...
> 

Agreed.

> 
> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny  wrote:
> 
> Bottom line, I think some changes are required in Fortress, to stp using
> InetOrgPerson. Changes in Commander are certainly going to be heavy...

This is an excellent discussion but I feel like we’re contemplating a difficult 
leap where the gains are not clear.  Who out there is asking to not use 
inetorgperson structural object class?  If they’re out there I’ve not heard 
from them.

Shawn

Re: Custom object classes and attributes

> 
> On Oct 20, 2016, at 9:38 AM, Patrick Brunmayr  wrote:
> 
> In my opinion ftProps is very proprietary to Fortress isn't it ?
> 

Yes, of course.  All fortress schema elements are prepended with ‘ft’.  But why 
does that matter?

> 
> On Oct 20, 2016, at 9:38 AM, Patrick Brunmayr  wrote:
> 
> Assigning object classes and attributes in LDAP is a proven thing where even 
> third party clients can do this without having the knowledge how to write 
> this ftProps thing.
> 
> How can i query a value in ftProps via LDAP ?
> 
> How can i write it ?

Being discussed on another thread currently.

> 
> On Oct 20, 2016, at 9:38 AM, Patrick Brunmayr  wrote:
> 
> This Midpoint integration thing is exactly the case of building a identity 
> federation. Fortress is one part of it

Agreed, we’re not driving this bus but we’ve got a seat on it.

Shawn

Re: Custom object classes and attributes


> On Oct 20, 2016, at 9:26 AM, Steve Moyer  wrote:
> 
> 
> With the trend towards federating identities and their related objects, would 
> it make sense to generically provide the same functionality through Fortress? 
>  Perhaps by adding a source name and source reference to every FortEntity 
> type?
> 
> We've also been discussing the fact that the FortEntity types all have the 
> ftProps attribute but only the User provides methods to access them.  If the 
> ftProps were exposed on every FortEntity type, you could (even more 
> generically) add a ftProps attribute with a value of (e.g.) 
> midpointObject:dn=...

This seems a simpler approach than exposing callbacks on the rbac entities.

Re: Custom object classes and attributes


> On Oct 20, 2016, at 9:05 AM, Patrick Brunmayr  wrote:
> 
> Lets asume one is using Fortress as a central place for RBAC. Over time
> there will be a lot or roles and groups
> 
> for different things. As an integrator to other systems like in my case
> Midpoint i am not interested in transfering all roles and groups.
> 
> So my approach would be to write some aux classes and assign them to the
> roles and groups. For instance auxclass MidpointObject.
> 
> In my Midpoint connector i would only fetch roles and groups which have
> aux class MidpointObject assigned.
> 
> So i can only provide really those things which are midpoint specific
> and not roles or groups which may not be of interest or even
> 
> more import which security wise relevant.
> 
> One use case for me would be i dont want to transfer all the Fortress
> Roles to Midpoint where one would gain access to Fortress :)
> 
> Does that make sense ?

Not quite.  You need a discriminator to specify whether a given object was 
processed by midpoint or not?  In other words if the object was created via a 
midpoint intermediary, you would decorate it with the objectclass attribute?  
What’s the rationale for that?

Re: Custom object classes and attributes

> 
> On Oct 20, 2016, at 8:43 AM, Steve Moyer  wrote:
> 
> Looking through the AdminMgr methods, I'd propose the following methods be 
> added to the interface (I'll turn it into a Jira issue when we're done with 
> the discussion):
> 
> User addUser(User user, EntryCallback callback);
> void deleteUser(User user, EntryCallback callback);
> User updateUser(User user, EntryCallback callback);
> 
> The User class would need one additional method - this would be very useful 
> just to further inspect retrieved objects but is also required within an 
> EntryCallback:
> 
> Entry getEntry();
> 
> The EntryCallback interface would look something like:
> 
> @FunctionalInterface
> public interface EntryCallback {
> 
>Entry transform(T fortressEntity) throws FortressOperationAbortedException;
> 
> }


Steve, why do say that the callback req’s the getEntry on entity?  Why couldn’t 
it go on the interface?
> Entry transform(T fortressEntity, LdapEntry entry) throws 
> FortressOperationAbortedException;


> 
> On Oct 20, 2016, at 8:43 AM, Steve Moyer  wrote:
> 
> I originally excluded the use of a callback on the delete operation but 
> having a callback allows the operation to be aborted (Based on values in the 
> entry?  Or when referential integrity with other entries might be violated?). 
>  As noted, having access to the underlying groupOfNames entry would also be 
> useful.  I'd argue that you would commonly expect User and Group to be more 
> complex than Fortress' view of them since it's common to write schema 
> extensions for them.  I'd also argue that Roles, Permissions, etc are 
> specifically Fortress implementations of the RBAC specification and they 
> should remain black boxes to other LDAP operations.
> 
> What do you think?

+1 (other than not exposing the model to the ldapentry)  

Agree that only user and groups are extended in this way.  The other entities 
should be left alone, excepting some sort of generic property capability.

Shawn

Re: Custom object classes and attributes

2016-10-21 Thread Emmanuel Lecharny

It's not important, it's just very convenient.

Le vendredi 21 octobre 2016, Patrick Brunmayr  a
écrit :

> Some very valid aspects here :)
>
> The kind of question is what makes InetOrgPerson so important ? In my
> understanding a basic user is
>
> about uid and a password. Thats very abstract but the minimal form of a an
> identity
>
>
> Am 20.10.2016 um 16:51 schrieb Emmanuel Lécharny:
>
> Some thoughts about Users and fortress (I have read teh full thread, and
> there are many aspects being discussed, I'd like to provide some general
> ideas here, nt to reply to any specific question).
>
>
> Fortress uses its own AttributeType and ObjectClasses, and relies on
> existing ObjectClasses : typically, InetOrgPerson for Users. The other
> Fortress objectClasses are AUXILLIARY, and taht allows any entry to be
> extended with attributes that are no conflicing with any STRUCTURAL
> ObjectClass.
>
>
> The thing is that an Entry in LDAP *must* have a STRUCTURAL ObjectClass,
> otherwise you won't be able to add it. This is the reson Fortress is
> using InetOrgPerson.
>
>
> Now, that does not fit everyone, because you may want to use a different
> STRUCTURAL ObjectClass, and that is not possible if it's not inheriting
> from InetOrgPerson in this case.
>
> One option would be to let the developper to decide which STRUCTURAL
> class should be the root of the Users Entries, but that does not fit
> well with Fortress, because te 'cn' and 'sn' attributes are mandatory in
> te InetOgPerson ObjectClass. Moreover, Fortress is expecing may of the
> InetOrgPerson attributeType to be present...
>
>
> The idea would be for Fortress to still let the user select which
> STRUCTURAL ObjectClass to use, and to default to a specific FortressUser
> STRUCTURAL ObjectClass, taht would mimic InetOrgPerson (but wth no
> mandatory attributeTypes). All teh needed attributes will be defined
> into AUXILLIARY ObjectClasses (including cn and sn).
>
>
> Fro teh API point of view, thsi is easy, and it will just require a
> configuration: the STRUCTURAL to use.
>
>
> From Commander POV (the UI), that is a different story. The point being
> that it's impossible to anticipate all the possible needs for all the
> possible application out there. One solution would be to expose the User
> using a tabular representation, regardless of the attribute content and
> order (that means we lose all teh semantic). Anothe roption, way more
> complex, would be to define templates that will be specific : they will
> tell teh GUI what and how to expose the data. This is definitively be a
> very complex change in Commander...
>
>
> Bottom line, I think some changes are required in Fortress, to stp using
> InetOrgPerson. Changes in Commander are certainly going to be heavy...
>
>
> Le 18/10/16 à 11:30, Patrick Brunmayr a écrit :
>
>
> Hi
>
> In my understanding Apache Fortress claims the sovereignty over creating
> users. Thats just fine but i see a problem here. After reading the
> docs here
>
> https://directory.apache.org/fortress/gen-docs/latest/apidoc
> s/org/apache/directory/fortress/core/AdminMgr.html#addUser-
> org.apache.directory.fortress.core.model.User-
>
>
> there is no way of assigning custom auxialiary object classes or
> attributes to the user. The user just represents inetOrgPerson which in
> most of the cases will be fine.
>
> In our scenario users MUST have two extra auxialiary object classes and
> some extra attributes set to be a valid user. ( I know about ftProps but
> these represent no attributes )
>
> I am writing an adapter which transfers users from different systems
> into Apache Fortress by using the AdminMgr. My problem is calling
> addUser may create a valid inetOrgPerson object
>
> but not a valid user object for our system. I would need to make an
> extra LDAP call to assign this object classes and attributes. This would
> even make the web interface quite unusable for our admins
>
> beacause we can not manage our users on a central place. Apache Fortress
> may create a valid inetOrgPerson but i would need an extra UI or config
> tool to set the other
>
> object classes.
>
>
> What can i do about this ?
>
> Thank u
>
>
> LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
> A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0,
> E-Mail: i...@linzag.at
>
>
>
>
>
>
>
> LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
> A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0,
> E-Mail: i...@linzag.at
>
>
>

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Custom object classes and attributes

2016-10-21 Thread Patrick Brunmayr

Some very valid aspects here :)

The kind of question is what makes InetOrgPerson so important ? In my
understanding a basic user is

about uid and a password. Thats very abstract but the minimal form of a an
identity

Am 20.10.2016 um 16:51 schrieb Emmanuel Lécharny:

Some thoughts about Users and fortress (I have read teh full thread, and
there are many aspects being discussed, I'd like to provide some general
ideas here, nt to reply to any specific question).

Fortress uses its own AttributeType and ObjectClasses, and relies on
existing ObjectClasses : typically, InetOrgPerson for Users. The other
Fortress objectClasses are AUXILLIARY, and taht allows any entry to be
extended with attributes that are no conflicing with any STRUCTURAL
ObjectClass.

The thing is that an Entry in LDAP *must* have a STRUCTURAL ObjectClass,
otherwise you won't be able to add it. This is the reson Fortress is
using InetOrgPerson.

Now, that does not fit everyone, because you may want to use a different
STRUCTURAL ObjectClass, and that is not possible if it's not inheriting
from InetOrgPerson in this case.

One option would be to let the developper to decide which STRUCTURAL
class should be the root of the Users Entries, but that does not fit
well with Fortress, because te 'cn' and 'sn' attributes are mandatory in
te InetOgPerson ObjectClass. Moreover, Fortress is expecing may of the
InetOrgPerson attributeType to be present...

The idea would be for Fortress to still let the user select which
STRUCTURAL ObjectClass to use, and to default to a specific FortressUser
STRUCTURAL ObjectClass, taht would mimic InetOrgPerson (but wth no
mandatory attributeTypes). All teh needed attributes will be defined
into AUXILLIARY ObjectClasses (including cn and sn).

Fro teh API point of view, thsi is easy, and it will just require a
configuration: the STRUCTURAL to use.

From Commander POV (the UI), that is a different story. The point being

that it's impossible to anticipate all the possible needs for all the
possible application out there. One solution would be to expose the User
using a tabular representation, regardless of the attribute content and
order (that means we lose all teh semantic). Anothe roption, way more
complex, would be to define templates that will be specific : they will
tell teh GUI what and how to expose the data. This is definitively be a
very complex change in Commander...

Bottom line, I think some changes are required in Fortress, to stp using
InetOrgPerson. Changes in Commander are certainly going to be heavy...

Le 18/10/16 à 11:30, Patrick Brunmayr a écrit :

In my understanding Apache Fortress claims the sovereignty over creating
users. Thats just fine but i see a problem here. After reading the
docs here

https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AdminMgr.html#addUser-org.apache.directory.fortress.core.model.User-

there is no way of assigning custom auxialiary object classes or
attributes to the user. The user just represents inetOrgPerson which in
most of the cases will be fine.

In our scenario users MUST have two extra auxialiary object classes and
some extra attributes set to be a valid user. ( I know about ftProps but
these represent no attributes )

I am writing an adapter which transfers users from different systems
into Apache Fortress by using the AdminMgr. My problem is calling
addUser may create a valid inetOrgPerson object

but not a valid user object for our system. I would need to make an
extra LDAP call to assign this object classes and attributes. This would
even make the web interface quite unusable for our admins

beacause we can not manage our users on a central place. Apache Fortress
may create a valid inetOrgPerson but i would need an extra UI or config
tool to set the other

object classes.

What can i do about this ?

Thank u

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0,
E-Mail: i...@linzag.at

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail:
i...@linzag.at

Re: Custom object classes and attributes

2016-10-20 Thread Emmanuel Lécharny

Some thoughts about Users and fortress (I have read teh full thread, and
there are many aspects being discussed, I'd like to provide some general
ideas here, nt to reply to any specific question).


Fortress uses its own AttributeType and ObjectClasses, and relies on
existing ObjectClasses : typically, InetOrgPerson for Users. The other
Fortress objectClasses are AUXILLIARY, and taht allows any entry to be
extended with attributes that are no conflicing with any STRUCTURAL
ObjectClass.


The thing is that an Entry in LDAP *must* have a STRUCTURAL ObjectClass,
otherwise you won't be able to add it. This is the reson Fortress is
using InetOrgPerson.


Now, that does not fit everyone, because you may want to use a different
STRUCTURAL ObjectClass, and that is not possible if it's not inheriting
from InetOrgPerson in this case.

One option would be to let the developper to decide which STRUCTURAL
class should be the root of the Users Entries, but that does not fit
well with Fortress, because te 'cn' and 'sn' attributes are mandatory in
te InetOgPerson ObjectClass. Moreover, Fortress is expecing may of the
InetOrgPerson attributeType to be present...


The idea would be for Fortress to still let the user select which
STRUCTURAL ObjectClass to use, and to default to a specific FortressUser
STRUCTURAL ObjectClass, taht would mimic InetOrgPerson (but wth no
mandatory attributeTypes). All teh needed attributes will be defined
into AUXILLIARY ObjectClasses (including cn and sn).


Fro teh API point of view, thsi is easy, and it will just require a
configuration: the STRUCTURAL to use.


>From Commander POV (the UI), that is a different story. The point being
that it's impossible to anticipate all the possible needs for all the
possible application out there. One solution would be to expose the User
using a tabular representation, regardless of the attribute content and
order (that means we lose all teh semantic). Anothe roption, way more
complex, would be to define templates that will be specific : they will
tell teh GUI what and how to expose the data. This is definitively be a
very complex change in Commander...


Bottom line, I think some changes are required in Fortress, to stp using
InetOrgPerson. Changes in Commander are certainly going to be heavy...


Le 18/10/16 à 11:30, Patrick Brunmayr a écrit :
> Hi
>
> In my understanding Apache Fortress claims the sovereignty over creating
> users. Thats just fine but i see a problem here. After reading the
> docs here
>
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AdminMgr.html#addUser-org.apache.directory.fortress.core.model.User-
>
>
> there is no way of assigning custom auxialiary object classes or
> attributes to the user. The user just represents inetOrgPerson which in
> most of the cases will be fine.
>
> In our scenario users MUST have two extra auxialiary object classes and
> some extra attributes set to be a valid user. ( I know about ftProps but
> these represent no attributes )
>
> I am writing an adapter which transfers users from different systems
> into Apache Fortress by using the AdminMgr. My problem is calling
> addUser may create a valid inetOrgPerson object
>
> but not a valid user object for our system. I would need to make an
> extra LDAP call to assign this object classes and attributes. This would
> even make the web interface quite unusable for our admins
>
> beacause we can not manage our users on a central place. Apache Fortress
> may create a valid inetOrgPerson but i would need an extra UI or config
> tool to set the other
>
> object classes.
>
>
> What can i do about this ?
>
> Thank u
>
>
> LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
> A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0,
> E-Mail: i...@linzag.at
>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Custom object classes and attributes

2016-10-20 Thread Patrick Brunmayr


In my opinion ftProps is very proprietary to Fortress isn't it ?

Assigning object classes and attributes in LDAP is a proven thing where even 
third party clients can do this without having the knowledge how to write this 
ftProps thing.

How can i query a value in ftProps via LDAP ?

How can i write it ?

This Midpoint integration thing is exactly the case of building a identity 
federation. Fortress is one part of it

thx

Am 20.10.2016 um 16:26 schrieb Steve Moyer:

Yes ... that makes sense.

With the trend towards federating identities and their related objects, would 
it make sense to generically provide the same functionality through Fortress?  
Perhaps by adding a source name and source reference to every FortEntity type?

We've also been discussing the fact that the FortEntity types all have the 
ftProps attribute but only the User provides methods to access them.  If the 
ftProps were exposed on every FortEntity type, you could (even more 
generically) add a ftProps attribute with a value of (e.g.) 
midpointObject:dn=...

Steve

"And so I pretend not to hear her. And go out to get an envelope because I'm going 
to have a hell of a good time in the process of buying one envelope. I meet a lot of 
people. And, see some great looking babes. And a fire engine goes by. And I give them the 
thumbs up. And, and ask a woman what kind of dog that is. And, and I don't know. The 
moral of the story is, is we're here on Earth to fart around. And, of course, the 
computers will do us out of that. And, what the computer people don't realize, or they 
don't care, is we're dancing animals. You know, we love to move around. And, we're not 
supposed to dance at all anymore."

- Kurt Vonnegut

- Original Message -
From: "Patrick Brunmayr" <mailto:p.brunm...@linzag.at>
To: fortress@directory.apache.org<mailto:fortress@directory.apache.org>
Sent: Thursday, October 20, 2016 10:05:30 AM
Subject: Re: Custom object classes and attributes

Lets asume one is using Fortress as a central place for RBAC. Over time
there will be a lot or roles and groups

for different things. As an integrator to other systems like in my case
Midpoint i am not interested in transfering all roles and groups.

So my approach would be to write some aux classes and assign them to the
roles and groups. For instance auxclass MidpointObject.

In my Midpoint connector i would only fetch roles and groups which have
aux class MidpointObject assigned.

So i can only provide really those things which are midpoint specific
and not roles or groups which may not be of interest or even

more import which security wise relevant.

One use case for me would be i dont want to transfer all the Fortress
Roles to Midpoint where one would gain access to Fortress :)

Does that make sense ?



Am 20.10.2016 um 15:00 schrieb Shawn McKinney:


On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr 
<mailto:p.brunm...@linzag.at> wrote:

- Please consider the possibility also for Groups or Roles


I get groups but why roles?  Can you provide a specific use case of what those 
attributes would be and why?



On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr 
<mailto:p.brunm...@linzag.at> wrote:

- It should also be possible to set/get these extra data through the
REST interface


Agreed.  Everything that can be done via api call must also be doable via rest.





LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at<mailto:i...@linzag.at>


--
Patrick Brunmayr
LINZ AG TELEKOM
Infrastruktur & Netzwerktechnik
Internet Services

Die LINZ AG TELEKOM ist ein Geschäftsbereich der LINZ STROM GmbH
für Energieerzeugung, -handel, -dienstleistungen und Telekommunikation.

4021 Linz,  Wiener Straße 151, Austria
Tel.:+43(0)732/3400-5639
Fax:+43(0)732/3400-155639
E-Mail:p.brunm...@linzag.at<mailto:p.brunm...@linzag.at>
Internet:  www.linzag-telekom.at<http://www.linzag-telekom.at>

FN 199533 g des Landesgerichtes Linz
Zertifiziert nach:
EN ISO   9001 Qualitätsmanagement (QM)
OHSAS 18001 Arbeitsschutzmanagementsystem
ISO/IEC 27001 Informationssicherheits-Managementsystem (ISMS)




LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-20 Thread Steve Moyer

Yes ... that makes sense.

With the trend towards federating identities and their related objects, would 
it make sense to generically provide the same functionality through Fortress?  
Perhaps by adding a source name and source reference to every FortEntity type?

We've also been discussing the fact that the FortEntity types all have the 
ftProps attribute but only the User provides methods to access them.  If the 
ftProps were exposed on every FortEntity type, you could (even more 
generically) add a ftProps attribute with a value of (e.g.) 
midpointObject:dn=...

Steve

"And so I pretend not to hear her. And go out to get an envelope because I'm 
going to have a hell of a good time in the process of buying one envelope. I 
meet a lot of people. And, see some great looking babes. And a fire engine goes 
by. And I give them the thumbs up. And, and ask a woman what kind of dog that 
is. And, and I don't know. The moral of the story is, is we're here on Earth to 
fart around. And, of course, the computers will do us out of that. And, what 
the computer people don't realize, or they don't care, is we're dancing 
animals. You know, we love to move around. And, we're not supposed to dance at 
all anymore."

- Kurt Vonnegut

- Original Message -
From: "Patrick Brunmayr" 
To: fortress@directory.apache.org
Sent: Thursday, October 20, 2016 10:05:30 AM
Subject: Re: Custom object classes and attributes

Lets asume one is using Fortress as a central place for RBAC. Over time
there will be a lot or roles and groups

for different things. As an integrator to other systems like in my case
Midpoint i am not interested in transfering all roles and groups.

So my approach would be to write some aux classes and assign them to the
roles and groups. For instance auxclass MidpointObject.

In my Midpoint connector i would only fetch roles and groups which have
aux class MidpointObject assigned.

So i can only provide really those things which are midpoint specific
and not roles or groups which may not be of interest or even

more import which security wise relevant.

One use case for me would be i dont want to transfer all the Fortress
Roles to Midpoint where one would gain access to Fortress :)

Does that make sense ?

Am 20.10.2016 um 15:00 schrieb Shawn McKinney:
>> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
>>
>> - Please consider the possibility also for Groups or Roles
> I get groups but why roles?  Can you provide a specific use case of what 
> those attributes would be and why?
>
>> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
>>
>> - It should also be possible to set/get these extra data through the
>> REST interface
> Agreed.  Everything that can be done via api call must also be doable via 
> rest.

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-20 Thread Patrick Brunmayr


Lets asume one is using Fortress as a central place for RBAC. Over time
there will be a lot or roles and groups

for different things. As an integrator to other systems like in my case
Midpoint i am not interested in transfering all roles and groups.

So my approach would be to write some aux classes and assign them to the
roles and groups. For instance auxclass MidpointObject.

In my Midpoint connector i would only fetch roles and groups which have
aux class MidpointObject assigned.

So i can only provide really those things which are midpoint specific
and not roles or groups which may not be of interest or even

more import which security wise relevant.

One use case for me would be i dont want to transfer all the Fortress
Roles to Midpoint where one would gain access to Fortress :)

Does that make sense ?



Am 20.10.2016 um 15:00 schrieb Shawn McKinney:

On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:

- Please consider the possibility also for Groups or Roles

I get groups but why roles?  Can you provide a specific use case of what those 
attributes would be and why?


On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:

- It should also be possible to set/get these extra data through the
REST interface

Agreed.  Everything that can be done via api call must also be doable via rest.




LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-20 Thread Steve Moyer

Looking through the AdminMgr methods, I'd propose the following methods be 
added to the interface (I'll turn it into a Jira issue when we're done with the 
discussion):

User addUser(User user, EntryCallback callback);
void deleteUser(User user, EntryCallback callback);
User updateUser(User user, EntryCallback callback);

The User class would need one additional method - this would be very useful 
just to further inspect retrieved objects but is also required within an 
EntryCallback:

Entry getEntry();

The EntryCallback interface would look something like:

@FunctionalInterface
public interface EntryCallback {

Entry transform(T fortressEntity) throws FortressOperationAbortedException;

}

I originally excluded the use of a callback on the delete operation but having 
a callback allows the operation to be aborted (Based on values in the entry?  
Or when referential integrity with other entries might be violated?).  As 
noted, having access to the underlying groupOfNames entry would also be useful. 
 I'd argue that you would commonly expect User and Group to be more complex 
than Fortress' view of them since it's common to write schema extensions for 
them.  I'd also argue that Roles, Permissions, etc are specifically Fortress 
implementations of the RBAC specification and they should remain black boxes to 
other LDAP operations.

What do you think?

Steve

"And so I pretend not to hear her. And go out to get an envelope because I'm 
going to have a hell of a good time in the process of buying one envelope. I 
meet a lot of people. And, see some great looking babes. And a fire engine goes 
by. And I give them the thumbs up. And, and ask a woman what kind of dog that 
is. And, and I don't know. The moral of the story is, is we're here on Earth to 
fart around. And, of course, the computers will do us out of that. And, what 
the computer people don't realize, or they don't care, is we're dancing 
animals. You know, we love to move around. And, we're not supposed to dance at 
all anymore."

- Kurt Vonnegut

- Original Message -
From: "Shawn McKinney" 
To: fortress@directory.apache.org
Sent: Thursday, October 20, 2016 9:00:51 AM
Subject: Re: Custom object classes and attributes

> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
> 
> - Please consider the possibility also for Groups or Roles

I get groups but why roles?  Can you provide a specific use case of what those 
attributes would be and why?

> 
> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
> 
> - It should also be possible to set/get these extra data through the
> REST interface

Agreed.  Everything that can be done via api call must also be doable via rest.

Re: Custom object classes and attributes

2016-10-20 Thread Shawn McKinney



> On Oct 20, 2016, at 2:37 AM, Patrick Brunmayr  wrote:
> 
> So how can Fortress handle this if it does not know about the specific
> user instance ?
> 
> How do you pass extra auxClasses and attributes in a REST way ?
> 
> Just some thoughts

Fortress uses JAXB to marshall its entities back and forth into XML.  We 
discussed before that for user the extension point will be its entity.

package com.mycompany.whatever;

@XmlRootElement(name = “weMyUser")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = “myuser", propOrder =
{
“foo1",
“foo2",
“foo3",
...
})
public class MyUser extends org.apache.directory.fortress.core.model.User()
{} 

Next that new object, myuser, will need to be registered with the fortress xml 
registry for jaxb (in some way)

https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/model/ObjectFactory.java

After the new classes mods have been made, they’ll need to be made available to 
the runtime by bundling this jar in with fortress-rest war.

Sha

Re: Custom object classes and attributes

2016-10-20 Thread Shawn McKinney

> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
> 
> - Please consider the possibility also for Groups or Roles

I get groups but why roles?  Can you provide a specific use case of what those 
attributes would be and why?

> 
> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr  wrote:
> 
> - It should also be possible to set/get these extra data through the
> REST interface

Agreed.  Everything that can be done via api call must also be doable via rest.

Re: Custom object classes and attributes

2016-10-20 Thread Patrick Brunmayr


Another important point to mention is the possibility to reflect this
extensibility also in the REST interface.

Why ?

Thats import if you dont have access to a JAVA env and the only way to
communicate is via REST.

So how can Fortress handle this if it does not know about the specific
user instance ?

How do you pass extra auxClasses and attributes in a REST way ?

Just some thoughts

Thx


LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-19 Thread Patrick Brunmayr


- Please consider the possibility also for Groups or Roles

- It should also be possible to set/get these extra data through the
REST interface

Thanks

Am 20.10.2016 um 00:30 schrieb Shawn McKinney:

On Oct 19, 2016, at 12:50 PM, Steve Moyer  wrote:

I'm liking the idea of a callback more and more.  One additional question - if 
we retrieve a User via the Fortress API, is the underlying inetOrgPerson 
preserved with the current modify method(s)?

Steve,

The updates are simple as can be.  Null attributes are ignored, anything 
not-null will be replaced with whatever is passed in the entity.

You may read prior to update and use that to pass into update which will simply 
replace the values with the new values, which probably is what was already 
present, unless attribute values are changed (by you the caller) after the read.

Does that answer the question?

Thanks,
Shawn




LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

> On Oct 19, 2016, at 12:50 PM, Steve Moyer  wrote:
> 
> I'm liking the idea of a callback more and more.  One additional question - 
> if we retrieve a User via the Fortress API, is the underlying inetOrgPerson 
> preserved with the current modify method(s)?

Steve,

The updates are simple as can be.  Null attributes are ignored, anything 
not-null will be replaced with whatever is passed in the entity.

You may read prior to update and use that to pass into update which will simply 
replace the values with the new values, which probably is what was already 
present, unless attribute values are changed (by you the caller) after the read.

Does that answer the question?

Thanks,
Shawn

Re: Custom object classes and attributes


> On Oct 19, 2016, at 11:08 AM, Chris Pike  wrote:
> 
> Not through the query builder, I was just suggesting it as an easy way to 
> allow extensible searching.

Agreed.  Wonder how we can combine with the other two req’s.

Re: Custom object classes and attributes

2016-10-19 Thread Steve Moyer

As we discussed yesterday, I'm still in favor of a getEntry() method for 
retrieving the underlying LDAP representation.  I'm still thinking through what 
the best method signature would be for creating and modifying User objects that 
have "cargo data" (extra LDAP attributes).  I'm liking the idea of a callback 
more and more.  One additional question - if we retrieve a User via the 
Fortress API, is the underlying inetOrgPerson preserved with the current modify 
method(s)?

Steve

"And so I pretend not to hear her. And go out to get an envelope because I'm 
going to have a hell of a good time in the process of buying one envelope. I 
meet a lot of people. And, see some great looking babes. And a fire engine goes 
by. And I give them the thumbs up. And, and ask a woman what kind of dog that 
is. And, and I don't know. The moral of the story is, is we're here on Earth to 
fart around. And, of course, the computers will do us out of that. And, what 
the computer people don't realize, or they don't care, is we're dancing 
animals. You know, we love to move around. And, we're not supposed to dance at 
all anymore."

- Kurt Vonnegut

- Original Message -
From: "Chris Pike" 
To: fortress@directory.apache.org
Sent: Wednesday, October 19, 2016 12:08:21 PM
Subject: Re: Custom object classes and attributes

Not through the query builder, I was just suggesting it as an easy way to allow 
extensible searching. 

- Original Message -
From: "Shawn McKinney" 
To: fortress@directory.apache.org
Sent: Wednesday, October 19, 2016 10:47:14 AM
Subject: Re: Custom object classes and attributes

> On Oct 19, 2016, at 9:25 AM, Chris Pike  wrote:
> 
> As far as querying is concerned, if we add a findUsers method that accepts a 
> query builder. You can just subclass the UserQueryBuilder, add your own 
> custom filter methods, then just pass that to the findUsers methods.

That will work for the filters but how do we select which attributes to pull 
back from the entries, and that gets loaded into the result set, will the 
caller have control of that as well?

Re: Custom object classes and attributes

2016-10-19 Thread Chris Pike

Not through the query builder, I was just suggesting it as an easy way to allow 
extensible searching. 

- Original Message -
From: "Shawn McKinney" 
To: fortress@directory.apache.org
Sent: Wednesday, October 19, 2016 10:47:14 AM
Subject: Re: Custom object classes and attributes

> On Oct 19, 2016, at 9:25 AM, Chris Pike  wrote:
> 
> As far as querying is concerned, if we add a findUsers method that accepts a 
> query builder. You can just subclass the UserQueryBuilder, add your own 
> custom filter methods, then just pass that to the findUsers methods.

That will work for the filters but how do we select which attributes to pull 
back from the entries, and that gets loaded into the result set, will the 
caller have control of that as well?

Re: Custom object classes and attributes

> On Oct 19, 2016, at 9:25 AM, Chris Pike  wrote:
> 
> As far as querying is concerned, if we add a findUsers method that accepts a 
> query builder. You can just subclass the UserQueryBuilder, add your own 
> custom filter methods, then just pass that to the findUsers methods.

That will work for the filters but how do we select which attributes to pull 
back from the entries, and that gets loaded into the result set, will the 
caller have control of that as well?

Re: Custom object classes and attributes

2016-10-19 Thread Chris Pike

As far as querying is concerned, if we add a findUsers method that accepts a 
query builder. You can just subclass the UserQueryBuilder, add your own custom 
filter methods, then just pass that to the findUsers methods.

- Original Message -
From: "Patrick Brunmayr" 
To: fortress@directory.apache.org
Sent: Wednesday, October 19, 2016 9:39:34 AM
Subject: Re: Custom object classes and attributes

I think there needs to be something like a "UserFactory" that can be set 
globally in the system. This factory creates

the concrete User instance whenever its needed and returns it back to Fortress. 
 And secondly there must be some kind of "Serializer" which

maps the LDAP node to the User instance. One would subclass this serializer and 
call the parent method to

the things that are already working. After the parent method you could then 
easily map the LDAP things to your

concrete instance. Just guessing but something like this.

We should also considering the "extension" posibility to other things like 
Groups or Roles. This would open great

flexibility in the system. For instance why not extending the Group with some 
additional info :)

Thx

Am 19.10.2016 um 15:28 schrieb Shawn McKinney:

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr 
<mailto:p.brunm...@linzag.at> wrote:

Of course this is a good idea but the User object anways smells like 
inetOrgPerson :)

You’ve got me there.  :-)

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr 
<mailto:p.brunm...@linzag.at> wrote:

My thoughts were more along the lines that you extend the user entity with your 
custom attributes.

Thats perfect. But there are several question

*   How can i get a list of all Users in Fortress API ?

*   How can i get a User by a Criteria ?

Checkout the reviewmgr:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html

To pull back all users:

List findUsers(new User(") );

or there are a few other searches you can do, by userid, role, org unit.

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr 
<mailto:p.brunm...@linzag.at> wrote:

*   How will Fortress handle to give me back my specific User class with the 
populated extra Fields. Remember i need to manipulate the User later and i need 
access to
my extra Fields.

That’s the question that begs asking.  I can again point to the idea of a 
callback module that gets inserted into the flow or perhaps Chris Pike’s work 
using the querybuilder will help us here.

The good news is you’re not the only one asking for this and it’s doable for a 
few methods, i.e. user add, update, search.

Shawn

--
Patrick Brunmayr
LINZ AG TELEKOM
Infrastruktur & Netzwerktechnik
Internet Services

Die LINZ AG TELEKOM ist ein Geschäftsbereich der LINZ STROM GmbH
für Energieerzeugung, -handel, -dienstleistungen und Telekommunikation.

4021 Linz,  Wiener Straße 151, Austria
Tel.:+43(0)732/3400-5639
Fax:+43(0)732/3400-155639
E-Mail:p.brunm...@linzag.at<mailto:p.brunm...@linzag.at>
Internet:  www.linzag-telekom.at<http://www.linzag-telekom.at>

FN 199533 g des Landesgerichtes Linz
Zertifiziert nach:
EN ISO   9001 Qualitätsmanagement (QM)
OHSAS 18001 Arbeitsschutzmanagementsystem
ISO/IEC 27001 Informationssicherheits-Managementsystem (ISMS)

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-19 Thread Patrick Brunmayr

I think there needs to be something like a "UserFactory" that can be set
globally in the system. This factory creates

the concrete User instance whenever its needed and returns it back to Fortress. And
secondly there must be some kind of "Serializer" which

maps the LDAP node to the User instance. One would subclass this serializer and
call the parent method to

the things that are already working. After the parent method you could then
easily map the LDAP things to your

concrete instance. Just guessing but something like this.

We should also considering the "extension" posibility to other things like
Groups or Roles. This would open great

flexibility in the system. For instance why not extending the Group with some
additional info :)

Thx

Am 19.10.2016 um 15:28 schrieb Shawn McKinney:

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr
wrote:

Of course this is a good idea but the User object anways smells like
inetOrgPerson :)

You’ve got me there. :-)

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr
wrote:

My thoughts were more along the lines that you extend the user entity with your
custom attributes.

Thats perfect. But there are several question

* How can i get a list of all Users in Fortress API ?

* How can i get a User by a Criteria ?

Checkout the reviewmgr:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html

To pull back all users:

List findUsers(new User(") );

or there are a few other searches you can do, by userid, role, org unit.

On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr
wrote:

* How will Fortress handle to give me back my specific User class with the
populated extra Fields. Remember i need to manipulate the User later and i need
access to
my extra Fields.

That’s the question that begs asking. I can again point to the idea of a
callback module that gets inserted into the flow or perhaps Chris Pike’s work
using the querybuilder will help us here.

The good news is you’re not the only one asking for this and it’s doable for a
few methods, i.e. user add, update, search.

Shawn

--
Patrick Brunmayr
LINZ AG TELEKOM
Infrastruktur & Netzwerktechnik
Internet Services

Die LINZ AG TELEKOM ist ein Geschäftsbereich der LINZ STROM GmbH
für Energieerzeugung, -handel, -dienstleistungen und Telekommunikation.

4021 Linz, Wiener Straße 151, Austria
Tel.:+43(0)732/3400-5639
Fax:+43(0)732/3400-155639
E-Mail:p.brunm...@linzag.at
Internet: www.linzag-telekom.at

FN 199533 g des Landesgerichtes Linz
Zertifiziert nach:
EN ISO 9001 Qualitätsmanagement (QM)
OHSAS 18001 Arbeitsschutzmanagementsystem
ISO/IEC 27001 Informationssicherheits-Managementsystem (ISMS)

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail:
i...@linzag.at

Re: Custom object classes and attributes

> On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr  wrote:
> 
> Of course this is a good idea but the User object anways smells like 
> inetOrgPerson :)
> 

You’ve got me there.  :-)

> 
> On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr  wrote:
> 
> My thoughts were more along the lines that you extend the user entity with 
> your custom attributes.
> 
> Thats perfect. But there are several question
> 
> *   How can i get a list of all Users in Fortress API ?
> 
> *   How can i get a User by a Criteria ?
> 

Checkout the reviewmgr:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html

To pull back all users:

List findUsers(new User(") );

or there are a few other searches you can do, by userid, role, org unit.

> 
> On Oct 19, 2016, at 1:40 AM, Patrick Brunmayr  wrote:
> 
> *   How will Fortress handle to give me back my specific User class with the 
> populated extra Fields. Remember i need to manipulate the User later and i 
> need access to
> my extra Fields.

That’s the question that begs asking.  I can again point to the idea of a 
callback module that gets inserted into the flow or perhaps Chris Pike’s work 
using the querybuilder will help us here.

The good news is you’re not the only one asking for this and it’s doable for a 
few methods, i.e. user add, update, search.

Shawn

Re: Custom object classes and attributes


Yes.  As a general rule we try to keep the ldap smell out of the api exposed to 
the caller.

Of course this is a good idea but the User object anways smells like 
inetOrgPerson :)

My thoughts were more along the lines that you extend the user entity with your 
custom attributes.

Thats perfect. But there are several question

 *   How can i get a list of all Users in Fortress API ?

 *   How can i get a User by a Criteria ?

 *   How will Fortress handle to give me back my specific User class with the 
populated extra Fields. Remember i need to manipulate the User later and i need 
access to
my extra Fields.

Just some thoughts :)

Am 18.10.2016 um 17:54 schrieb Shawn McKinney:




On Oct 18, 2016, at 9:47 AM, Patrick Brunmayr 
 wrote:

The questions is more where to make these changes! Is it useful to have some 
more generic methods on the User class like

*   getObjectClass
*   getAuxClasses
*   setAuxClasses
*   hasAuxClass
*   getAttributes
*   getAttribute
*   setAttribute
*   hasAttribute

Is this to LDAP specific ?




Yes.  As a general rule we try to keep the ldap smell out of the api exposed to 
the caller.

My thoughts were more along the lines that you extend the user entity with your 
custom attributes.

i.e.

public class MyUser extends User
{
…

}




On Oct 18, 2016, at 9:47 AM, Patrick Brunmayr 
 wrote:

Or another approach would be to have some kind of Eventlistener to react on the 
add and update methods. There
you get an LDAP connection and the user object as parameters. You can then 
implement your custom logic there.

More generic is to have access to the methods above and the add and update 
methods must check the extra
aux classes and attributes and reflect them back into LDAP.

Would be nice to have some kinde of configuration which extra classes to handle 
in the web UI. Then there
should be a the possibility to edit there attributes if its not much effort.




Yeah listener or callback that is registered.  i.e. myUserHandler (LDAPEntry 
le, User ue)

then you simply add the attributes that are needed by upcasting to your 
extended user object grabbing the attributes, adding to entry, and returning 
control to main method.

The web UI is a separate matter.  Doable, but not as simple.  Care would have 
to be taken to make it easy to upgrade.

Shawn




LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-18 Thread Shawn McKinney

> On Oct 18, 2016, at 9:47 AM, Patrick Brunmayr  wrote:
> 
> The questions is more where to make these changes! Is it useful to have some 
> more generic methods on the User class like
> 
> *   getObjectClass
> *   getAuxClasses
> *   setAuxClasses
> *   hasAuxClass
> *   getAttributes
> *   getAttribute
> *   setAttribute
> *   hasAttribute
> 
> Is this to LDAP specific ?
> 

Yes.  As a general rule we try to keep the ldap smell out of the api exposed to 
the caller.  

My thoughts were more along the lines that you extend the user entity with your 
custom attributes.

i.e.

public class MyUser extends User
{
…

}

> 
> On Oct 18, 2016, at 9:47 AM, Patrick Brunmayr  wrote:
> 
> Or another approach would be to have some kind of Eventlistener to react on 
> the add and update methods. There
> you get an LDAP connection and the user object as parameters. You can then 
> implement your custom logic there.
> 
> More generic is to have access to the methods above and the add and update 
> methods must check the extra
> aux classes and attributes and reflect them back into LDAP.
> 
> Would be nice to have some kinde of configuration which extra classes to 
> handle in the web UI. Then there
> should be a the possibility to edit there attributes if its not much effort.
> 

Yeah listener or callback that is registered.  i.e. myUserHandler (LDAPEntry 
le, User ue)

then you simply add the attributes that are needed by upcasting to your 
extended user object grabbing the attributes, adding to entry, and returning 
control to main method. 

The web UI is a separate matter.  Doable, but not as simple.  Care would have 
to be taken to make it easy to upgrade.

Shawn

Re: Custom object classes and attributes


The questions is more where to make these changes! Is it useful to have some 
more generic methods on the User class like

 *   getObjectClass
 *   getAuxClasses
 *   setAuxClasses
 *   hasAuxClass
 *   getAttributes
 *   getAttribute
 *   setAttribute
 *   hasAttribute

Is this to LDAP specific ?

Or another approach would be to have some kind of Eventlistener to react on the 
add and update methods. There
you get an LDAP connection and the user object as parameters. You can then 
implement your custom logic there.

More generic is to have access to the methods above and the add and update 
methods must check the extra
aux classes and attributes and reflect them back into LDAP.

Would be nice to have some kinde of configuration which extra classes to handle 
in the web UI. Then there
should be a the possibility to edit there attributes if its not much effort.



Am 18.10.2016 um 16:25 schrieb Shawn McKinney:





On Oct 18, 2016, at 9:15 AM, Patrick Brunmayr 
 wrote:

In my understanding Midpoint should not be responsible to take care of fortress 
attributes like ftProps or something else. Its up to the connector to make a 
transparent transfer

between the two systems in an API like way. So whenever something needs to be 
altered in Fortress the way should be via the AdminMg. Also the conenctor is 
responsible to

define what kind of schema it want to provide to midpoint. There is no need to 
sync ftPros or something else.




Let’s assume that we decide it’s a good idea to extend the fortress api to 
support custom user aux objects.  What would that change look like?

user add and update methods have some sort of call back for you to add your 
custom attributes to the ldap entity.

What else - user page in fortress web?  Or can midpoint handle the data 
collection part with its UI?

Shawn




LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail: 
i...@linzag.at

Re: Custom object classes and attributes

2016-10-18 Thread Shawn McKinney

> 
> On Oct 18, 2016, at 9:15 AM, Patrick Brunmayr  wrote:
> 
> In my understanding Midpoint should not be responsible to take care of 
> fortress attributes like ftProps or something else. Its up to the connector 
> to make a transparent transfer
> 
> between the two systems in an API like way. So whenever something needs to be 
> altered in Fortress the way should be via the AdminMg. Also the conenctor is 
> responsible to
> 
> define what kind of schema it want to provide to midpoint. There is no need 
> to sync ftPros or something else.
> 

Let’s assume that we decide it’s a good idea to extend the fortress api to 
support custom user aux objects.  What would that change look like?

user add and update methods have some sort of call back for you to add your 
custom attributes to the ldap entity.

What else - user page in fortress web?  Or can midpoint handle the data 
collection part with its UI?

Shawn

Re: Custom object classes and attributes

There are a couple of ways to look at this problem.

1. fortress as the caretaker of all the user attributes.

2. some other system as the caretaker of fortress attributes

I am open to the idea of adding an extension mechanism that would allow adding
custom aux classes into user add / updates. The amount of work is non-trivial
but not particularly difficult or unusual. Of course this would have to extend
past the core into the rest and web components.

But the 2nd option is probably the sensible approach. You mentioned midpoint
recently. We don’t know how to get it to manage fortress style attributes yet
but assuming it’s doable and considerably less than work than option 1.

The Penn State team uses a SCIM services to combine their edu attributes into
fortress (or perhaps vice versa). Some of that code has recently been donated
to this project and forms the basis of SCIMple.

In any case it’s a very good question. I’d like to hear from the community
what they think the best approach is.

Shawn

The reason i asked this question was like you mentioned my Midpoint
integration. I theoretically know how to do it. You have to write a custom
connector like in the docs here.

https://wiki.evolveum.com/display/midPoint/Connector+Development+Guide#ConnectorDevelopmentGuide-BasicPrinciples

The connector's task is just to sync back and forth objects from its source to
Midpoint. Thats were the AdminMgr comes into play :)

Whenever i am getting an event of "user creation" i need to pull data out of
the Midpoint object and then call the AdminMgr methods like addUser.

That just solves the basics. But currently if i would need to add some extra
information ( like aux classes or attributes ) i would have to open an extra
ldap conenction to update the

user object in the DIT. Thats just a bit of overhead because in the background
Fortress will also make a LDAP connection to create the user.

In my understanding Midpoint should not be responsible to take care of fortress
attributes like ftProps or something else. Its up to the connector to make a
transparent transfer

between the two systems in an API like way. So whenever something needs to be
altered in Fortress the way should be via the AdminMg. Also the conenctor is
responsible to

define what kind of schema it want to provide to midpoint. There is no need to
sync ftPros or something else.

LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste
A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, E-Mail:
i...@linzag.at

Re: Custom object classes and attributes

2016-10-18 Thread Shawn McKinney

> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr  wrote:
> 
> In my understanding Apache Fortress claims the sovereignty over creating
> users. Thats just fine but i see a problem here. After reading the docs here
> 
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AdminMgr.html#addUser-org.apache.directory.fortress.core.model.User-
> 
> there is no way of assigning custom auxialiary object classes or
> attributes to the user. The user just represents inetOrgPerson which in
> most of the cases will be fine.

Correct, inetorgperson + password + groups / roles

> 
> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr  wrote:
> 
> In our scenario users MUST have two extra auxialiary object classes and
> some extra attributes set to be a valid user. ( I know about ftProps but
> these represent no attributes )
> 

correct again, props are just name / value pairs.

> 
> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr  wrote:
> 
> I am writing an adapter which transfers users from different systems
> into Apache Fortress by using the AdminMgr. My problem is calling
> addUser may create a valid inetOrgPerson object
> 
> but not a valid user object for our system. I would need to make an
> extra LDAP call to assign this object classes and attributes. This would
> even make the web interface quite unusable for our admins
> 
> beacause we can not manage our users on a central place. Apache Fortress
> may create a valid inetOrgPerson but i would need an extra UI or config
> tool to set the other
> 
> object classes.
> 
> 
> What can i do about this ?

There are a couple of ways to look at this problem.

1. fortress as the caretaker of all the user attributes.

2. some other system as the caretaker of fortress attributes

I am open to the idea of adding an extension mechanism that would allow adding 
custom aux classes into user add / updates.  The amount of work is non-trivial 
but not particularly difficult or unusual.  Of course this would have to extend 
past the core into the rest and web components.

But the 2nd option is probably the sensible approach.  You mentioned midpoint 
recently.  We don’t know how to get it to manage fortress style attributes yet 
but assuming it’s doable and considerably less than work than option 1.  

The Penn State team uses a SCIM services to combine their edu attributes into 
fortress (or perhaps vice versa).  Some of that code has recently been donated 
to this project and forms the basis of SCIMple.

In any case it’s a very good question.  I’d like to hear from the community 
what they think the best approach is.

Shawn

Custom object classes and attributes