Re: Role Based access control
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 09/30/04
- Next message: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Previous message: Dagfinn Reiersol: "Re: XP Requirement Analysis?"
- Maybe in reply to: H. S. Lahman: "Re: Role Based access control"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Sep 2004 18:22:41 GMT
Responding to Nair...
> Let's take a Bug tracking application (for software projects)
> (web based) Here I have:
>
> Roles Processes that a role accesses
>
> Administrator Add New Projects
> Add Users
> Add Processes (Post bug, Assign Bug, Close a
> Bug...)
> Add Roles
> Activate/De Activate Users
> Assign PM/PL roles to a user
> Assign PM to a Project
>
> Project Manager(PM) Assign PL to a project
> View bug status of projects
> View various reports linked to a project
> Assign tester role to a user for a project
> View bug history of a project
> Project Leader(PL) Assign developer role to a user for a project
> View bug status of projects (assigned to him)
> Assign bug to a developer
> Re-assign a bug to a developer(if bug fix is
> not satisfactory)
> Close the bug (see below)
>
> Developer resolve bug assigned and post the details
> Tester post a bug to the system
> View previous bugs posted(by the same tester)
So much for my assumptions about external definitions/assignments. B-)
Clearly the Administrator role's processes do that /within/ the
application scope. Also, these roles aren't about hierarchical
privileges as I assumed; they really are roles in the sense of the GoF
State pattern. At least now I think I mostly understand what is going on.
>
>
> Just for clarification:
> A bug goes thru stages like:
> Open - (this is the default stage when a bug is posted by a
> tester)
> assigned - (when a bug is assigned to a developer by the PL)
> resolved - (when a developer resolves a bug and posts it's details
> in to the system)
> reassigned - (if the PL thinks that the bug fix is not satisfactory)
> closed - (once the bug fix is determined to be ok by the PL
>
> Clarification on the phrase "after logging in,
>
>>will be hown a menu, containing all the processes available to the
>>roles assigned to him"
>
>
> Let us say a PL logs in to the system. The
> menu displyed to a PL will be:
>
> Add a developer to a project
> Assign a bug to a developer
> Re-assign a bug to a developer
> Close a bug
> View summary report of a project
Why is only one PM task included with all the PL tasks. I understand
that the same person might be assigned to be both PM and PL for a
project. But wouldn't that mean they have access to /all/ processes of
both role? (I think you answer this below.)
> If tester logs in (and if assigned to one project)
> the menu displayed will be
> Post a bug
> View previous bugs
>
> If a user is working on multiple projects, he will have to select
> the project first(after login) and the appropriate menu will be
> displayed.
BTW, note that you have introduced a new entity relevant to assignments:
Project, which <may> act like an association object:
[Project]
|
* | *
[User] ------------------ [Role]
Uncovering such entities is why I keep pushing back on how the
assignments are made.
>
>
> The above menu is generated from based on the processes for that role.
> These menu items are added into the system by the administrator.
Are the processes for a role fixed across projects (i.e., a single
instance of each Role for all projects)? Or can the Administrator
tailor the Role for each Project by customizing what processes are
available to the Role? I am beginning to suspect the latter. In that
case, we have:
* R3
[User] -----------+
| * |
| played by | assigned to
| | 1
R1 |--------- [Project]
| | 1
| | tailored to
* | * |
[Role] -----------+
| 1 R4 [equal,R3,R1]
|
R2 |
| allows
| *
[Process]
where R1 is defined for the PM by the Administrator, for the PL by the
PM, and for the Developer/Tester by the PL. Meanwhile, R2 and R4 are
instantiated by the Administrator, presumably up front before any
assignments. This represents the customization of Role to Project.
(The relationship constraint simply specifies that one gets to the same
[Role] instances from a Project via R4 are one reaches via R3 -> R1.)
That leaves R3 to instantiate. That is likely done by the Administrator
for the PM, but what about the others? Are Users first assigned to the
Project so that role assignments are selected from a pool of predefined
Users for the Project? Or is R3 instantiated when an assignment to a
role is actually made? (I would expect the former to be more likely as
well as being easier to manage.)
Mechanically, I would expect whoever talks to the UI (User?) to navigate
R1 -> R2 to get the list of process names to display. The relationship
instantiation will ensure that whatever Processes are at the end of the
path are the ones the user has available for this Project. When the
user selects a process from the UI, that message would go directly to
the relevant Process. [Process] would likely be subclassed like a GoF
Strategy pattern with a generic doIt(DataPacket*) interface. To do
things like viewing bugs, all one needs to do is hang [BugList] and
[Bug] classes off [Process] and [Project] with appropriate
relationships. Then [Process] dispatches to the appropriate delegated
behavior in those classes.
Note that all of the Administrator's processes (except activation, which
is probably s simply attribute assignment) can be expressed in terms of
simply instantiating objects and relationships. In effect,
Administrator becomes a factory for initializing the application. Also,
the only real behavior lies in [Process] (and [BugList],[Bug]). Most of
the rules an policies of the system have been incorporated in rather
simple relationship instantiation. That makes the executable code simpler.
>
> The above menu will be displayed to a PL only after log in and
> after he selects a project(a PL may be assigned to more than one
> project).
>
> All the above roles may be working on multiple projects at the same
> time
> (except perhaps the developer, but we must provide for this
> eventuality too)
>
> This means the user will have to choose a project after a successful
> login.
If that is the case, then we can assume the R3 relationship is *:1
_during the execution of this application_ because the Project is
isolated during login. There will have to be a separate infrastructure
(lookup table?) associated with project selection, though, that
validates that the user is really assigned to the selected project. In
that context we need a second User:Project relationship that is *:*.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
- Next message: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Previous message: Dagfinn Reiersol: "Re: XP Requirement Analysis?"
- Maybe in reply to: H. S. Lahman: "Re: Role Based access control"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
