Great. I'll try this out Sent from my iPhone
On Jun 23, 2013, at 9:49 AM, David Tildesley <[email protected]> wrote: > > > James wrote: > >> No I am not building an Identity management system. I will take your advice >> though. I will use pwm to manage users but then how will I be able to use >> that in the domain model? When a user logs in, I want him to have access to >> some data only. In the ToDo application this is achieved with the ownedby >> property but I want to go beyond that and have the owned by to be an entity >> to which I can assign users. I can model the entity but I cannot get list >> of users from Isis. > > It's hard to offer advice when I don't know your problem domain. > However generally speaking it sounds like your "user" may be represented in > the application problem domain > and has a <<party>>"Person" entity instance which has some sort of <<role>> > relationship instance to one or more <<moment interval>> instances > If you don't know already, the concepts between the chevrons are archetypes > from Coad's colour modeling > which is nicely summarized in Dan's Haywood's book: "DDD using Naked Objects" > N.B. If the only thing of interest is the <<role>> and the "person" only has > one role, then you don't need the <<party>>"Person" entity. > So ... how do you get your <<party>>/<<role>> into your application as an > instance? Well it could come from a variety of sources: > > - Some other system as an integration or a ETL load. > - Synced from an LDAP directory > - Entered manually by some business person with administrator role > - via form based signup (for a service offered by your application > - or it could be provisioned just in time when the authentication user first > connects by using the user id to go and fetch Identity attributes from an > LDAP server user entry. e.g. the Identity may have an employee number which > fits in nicely with <<role>>Employee. > - or something else > > Once your <<party>>/<<role>> is in the system as an object instance, then > it's a matter of associating the <<role>> with the <<moment-interval>> and > driving the rest by domain behaviour. > > e.g. in an HR domain: a <<party>>Person has a role of <<role>>Employee > associated to an <<moment-interval>>Employment. > The <<moment-interval>>Employment has an association to > <<moment-interval>>PositionAssignment>> which has an association > to <<thing>> Position. <<thing>>Position has a role association of "manager" > to another <<thing>> Position. > If you can match the (logged in) user principal with a > <<party>>Person----<<role>>Employee then you can > invoke an operation on the user's <<role>>Employee, delegated to Employment > delegated to PositionAssignment > delegated to "Position" asking for the list of direct reports > (<List><<party>>Persons) managed by that <<role>>Employee > which would then allow some other operation to be done on the list of direct > reports by that user. > > Generally <<role>> archetypes have lots of domain specific behaviour > revolving around authorisation to act on some particular entity instance in > context. > > However don't get confused with roles that are used to map to coarse grained > access entitlements. > Shiro enforces down to what operation a user principal is able to invoke > based on > shiro configured role to operation mappings and what "roles" the Shiro realm > has determined that the user has (lookup from ldap) > (which in ISIS controls what behaviour a user "sees" in the application). > Domain behaviour takes over from there to determine whether the user > can do some action on a particular object instance. > > HTH. > David.
