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.
