> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
