Le 21/10/16 à 15:56, Shawn McKinney a écrit :
>> 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.
Then the best possible fit for your ObjectClass would be Account, or a
flavor of Account. It makes the uid attribute mandatory, and the ou
attribute as optionnal :
objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account'
SUP top
STRUCTURAL
MUST uid
MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
>
> 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.
Why is that ?
> 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?
It's all abot forcing the application to have a User that has to
implement an ObjectClass, above another. If one aplication based its
user on top of a specific ObjectClass, not inheriting from
InetOrgPerson, then they will have to redisign the application to use it
with fortress - or add some glue in the API calls...
As an API, we should probably avoid any adherence that makes it difficult
But i'm just expressing a concern, which may be addressed - or not -
later on. I just want to be sure that these aspects are being discussed.
