SitePoint Sponsor

User Tag List

Page 11 of 11 FirstFirst ... 7891011
Results 251 to 267 of 267
  1. #251
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    we have the following structure :

    access
    => role
    => action

    access is similiar to the typically used user_id for simple session based login stuff. role is a group of actions and actions are more or less fine grained permission definitions.
    now how will actions be used? is the role just a collection of actions or does it act more like a namespace? i mean i could use actions as a unique id for specific tasks and reuse them in different roles or i could just define them where needed.
    most examples given were more into the direction of treating roles as simple containers for actions. looking at this from the administration interface side would mean that we can't or shouldn't do too much magic for the role => actions relation. roles are dump containers which may or may not contain actions.

    basic usage :

    - add / edit / delete actions
    * deleting actions with references from roles is allowed
    * delete : delete all references by roles

    - add / edit / delete roles
    * deleting roles with assigned actions is allowed
    * delete : delete all references by accesses
    * delete : delete all references to actions

    - add / edit / delete accesses
    * deleting accesses with assigned roles is allowed
    * delete will delete all references to roles

    Sike

  2. #252
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One reason I haven't been trying to push this thread forward is that I'm seeing how difficult it is to do it right.

    But let me try to move ahead and be slightly more specific about some likely uses of this kind of component.

    • Login (basic access).
    • Authorization (access to features and/or objects).
    • Administration by an administrative user.
    • Self-registration and self-administration (like Sitepoint has, for example).


    The last item in particular raises a question we haven't discussed at all so far: how does the RBAC implementation mesh with other user data? Say you have a registration form that requires the user to give address information. How do you handle that relative to the RBAC information? You will likely be assigning a default role to the user account. How?

    As an example, the PEAR Auth module handles this coordination by letting you specify the names of tables and columns to store the data.
    Dagfinn Reiersřl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  3. #253
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    The last item in particular raises a question we haven't discussed at all so far: how does the RBAC implementation mesh with other user data? Say you have a registration form that requires the user to give address information. How do you handle that relative to the RBAC information? You will likely be assigning a default role to the user account. How?

    As an example, the PEAR Auth module handles this coordination by letting you specify the names of tables and columns to store the data.
    imho rbac should not try to do too much, just let the application handle all user profile / registration / login stuff. rbac should only provide a framework for permissions. the easyiest way would be that the application manages the releations between true users and rbac roles.


    Sike

  4. #254
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    [*]Login (basic access).
    Not part of our current scope I hope.

    Quote Originally Posted by dagfinn
    how does the RBAC implementation mesh with other user data?
    What is currently called access (access_id?) could be the username or the primary key into an authentication table or just a random MD5 type string. It is a pointer/link to the authentication information and would never contain any data of it's own.

    Quote Originally Posted by dagfinn
    As an example, the PEAR Auth module handles this coordination by letting you specify the names of tables and columns to store the data.
    I think we want to avoid that kind of mess if we can. It might be we can't, but it is really hard to see what the programmer API looks like at the one and a half iteration stage.

    How about we punt for a next iteration. Try to do just one use case for the next acceptance test along the lines of...
    1) Allow an access key a single role and a single permission.
    2) Access that permision to assert if it there.
    3) Remove that access or role and clean up.

    Basically just to implement it just to see what the code will look like. Then, if we don't like it, we can refactor or roll back. It would give us something more concrete to discuss.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #255
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Not part of our current scope I hope.
    I don't know what you mean by that. If "not part of our scope" means we won't implement it, I say maybe, maybe not.

    If you mean that we don't have to think about it, then I disagree. It's like saying we're building a car and the wheels are outside our scope. The slight problem is you can't drive the car without wheels. Even if someone else is supposed to put the wheels on, you can't design the rest of the car without thinking about the wheels.

    Quote Originally Posted by lastcraft
    What is currently called access (access_id?) could be the username or the primary key into an authentication table or just a random MD5 type string. It is a pointer/link to the authentication information and would never contain any data of it's own.
    Yes. The RBAC code could simply require something unique and not care whether it's MD5, a database ID, an email address or whatever.

    So let's say we're processing a self-registration form. Here's a very hypothetical piece of application code

    PHP Code:
    $someone = new AppSpecificUserAccount;
    $someone->setEmail($POST['email']);
    // (initialize the rest of the object)
    $someone->save();

    class 
    AppSpecificUserAccount...
    function 
    save() {
        
    //Save the stuff to a database table
        // (lots of code omitted)

        // Assign role
        
    $admin = new RBACAdministrator;
        
    $admin->assign($this->email'default_role');

    Assuming that the RBAC info is also in a database, this means the application may need to perform two queries every time someone logs in. We can live with that.

    It means that the Access object doesn't have to be explicitly stored in the RBAC database, since it's already stored somewhere else. But what about roles and permissions? I still can't see those being created implicitly, mostly because I can't see how that's compatible with any kind of civilized administrative user interface.
    Quote Originally Posted by lastcraft
    How about we punt for a next iteration. Try to do just one use case for the next acceptance test along the lines of...
    1) Allow an access key a single role and a single permission.
    2) Access that permision to assert if it there.
    3) Remove that access or role and clean up.

    Basically just to implement it just to see what the code will look like. Then, if we don't like it, we can refactor or roll back. It would give us something more concrete to discuss.
    We could simplify it to just a role with no permissions. It's enough for our hypothetical application writer to do some kind of authorization.

    But I still want to know how that role gets created. I don't think doing the implementation will give us any new insights into that.
    Dagfinn Reiersřl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  6. #256
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    I don't know what you mean by that. If "not part of our scope" means we won't implement it, I say maybe, maybe not.
    Yes. We won't (unless we get ambitious) implement authentication, but yes it does have implications.

    Quote Originally Posted by dagfinn
    Assuming that the RBAC info is also in a database, this means the application may need to perform two queries every time someone logs in. We can live with that.
    There may be ways around that too, but I agree it would be diminishing returns.

    Quote Originally Posted by dagfinn
    But what about roles and permissions? I still can't see those being created implicitly, mostly because I can't see how that's compatible with any kind of civilized administrative user interface.
    I can't either, but I have a suspicion it may be possible. If it was, and we figured out how, then that could be a real win. How about we try it and then change plan when we hit a brick wall? Beats just discussing it.

    Quote Originally Posted by dagfinn
    It's enough for our hypothetical application writer to do some kind of authorization.
    Sorry, my mistake. Yes, that's what I meant - verify the behaviour by testing the permission, not by asking the admin interface.

    Quote Originally Posted by dagfinn
    But I still want to know how that role gets created. I don't think doing the implementation will give us any new insights into that.
    No, but writing the test case will. I think getting the next test case up will be key as it will set the "style" of the interface.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #257
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can't comment on the quality of the code, but I notice that the new BlueWonder framework has an RBAC component...

    sourceforge.net/projects/bluewonder

  8. #258
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by auricle
    I can't comment on the quality of the code, but I notice that the new BlueWonder framework has an RBAC component...

    sourceforge.net/projects/bluewonder
    Thanks for the link. This is definitely something to download and check out.

    JT

  9. #259
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Germany -> Göttingen
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Sorry

    Sorry guys, but i hope noone in this thread has ever published such a bad nondocumented code before.
    I took a look and got frustrated. Thats less readable than compiled bytecode :-)

  10. #260
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Germany -> Göttingen
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well and maybe not that human readable than my english, but..

    By the way - i like your way of developing a really required `module' of RBAC in php.

  11. #261
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by chilla
    Sorry guys, but i hope noone in this thread has ever published such a bad nondocumented code before.
    I took a look and got frustrated. Thats less readable than compiled bytecode :-)
    Which bit (or do you mean the BlueYonder?) and what part didn't you understand? So far there has been depressingly little code, but when it's arrived I haven't found any of it unclear.

    For some of it you probably have to be used to the "tests as documentation" thing, but everyone has kept their methods short and well named.

    As for the rest of the thread I might attempt a possible "finish" as it's been pretty dormant.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #262
    SitePoint Addict
    Join Date
    Mar 2003
    Location
    Germany
    Posts
    216
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft

    As for the rest of the thread I might attempt a possible "finish" as it's been pretty dormant.

    yours, Marcus
    That would be great! Even if it's not 100% perfect or "pattern-based" or whatever, I think it would come very handy. And it was a bit sad to see this thread die without any real outcome, anyway. (Not that I would have been able to contribute, but I followed passively along with interest )

  13. #263
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Roles: Assigned to Identifiers and defines permissions/accessrights
    Permissions: Allows an operation to be performed on an object
    Operation: An action performed on an object
    Object: A part of the system protected by the RBAC module
    Identifier: Unique identifier. usually a normal user, but can be a machine/bot,etc.


    RBACGateway - Checks access to objects based on: Identifier, Roles and Permissions
    assigned to the active roles on that Identifier.

    RBACController - Adds/Deletes Roles and Permissions, Grants Permissions to Roles
    and assigns roles to Identifiers.

    RBACDataGateway - Performs the dataabstraction between the application and the backend,
    how this is supposed to be implemented so that the "client/user" of the
    system can choose a storage that fits that current projekt i dont hava a qlue on.



    RBACGateway usage:
    $gateway = new RBACGateway(new RBACDataGateway('current_identifier'));
    if($gateway->can('edit','articles'))
    {
    // user can perform "edit" on "articles"
    }

    RBACControler usage:
    $cont = new RBACController(new RBACDataGateway('current_identifier'));
    // Assignment
    $cont->newRole('some_role');
    $cont->assignPermission('delete','articles','some_role');
    // Deletion
    $cont->revokePermission('delete','articles','some_role');
    $cont->delRole('some_role');


    Maybee this is way to simple, am i missing something here?

    Well well, just my 2 cents.

  14. #264
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:

    $gateway 
    = new RBACGateway(new RBACDataGateway('current_identifier'));

    if(
    $gateway->can('edit','articles')) {
        
    // user can perform "edit" on "articles"
    }

    $cont = new RBACController(new RBACDataGateway('current_identifier'));

    // Assignment
    $cont->newRole('some_role');
    $cont->assignPermission('delete','articles','some_role');

    // Deletion
    $cont->revokePermission('delete','articles','some_role');
    $cont->delRole('some_role'); 

  15. #265
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ofcourse you will have a method that does something like:
    $cont->assignRole('some_role','some_identifier'); that adds the role to an identifier(an identifier can be a user, another machine, etc.)

  16. #266
    SitePoint Member
    Join Date
    Sep 2004
    Location
    germany
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question

    Quote Originally Posted by chilla
    Sorry guys, but i hope noone in this thread has ever published such a bad nondocumented code before.
    I took a look and got frustrated. Thats less readable than compiled bytecode :-)
    Hi,

    I'm one of the developers of BlueWonder and I have 2 questions to you:

    1. Why is the code bad?
    2. What kind of documentation you need?

    David

  17. #267
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    Bucharest, Romania
    Posts
    118
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    after some googleing about RBAC, found this thread.
    I spent some time reading all 11 pages, and I find the discussion very interesting. Too bad is discontinued...
    So I am posting this, to set this thread on a higher position.

    I started some time ago a Python project - authentication server:
    data exchange though https, xml formated, the client would send a request, the server process it and returns an xml result, RBAC approach, clients could set up the users, roles, resources, actions (unlimited number, user defined), etc.
    (data exchange should be similar to UPS, FedEx xml apis..)
    It was designed to run intranet (data exchange could take time using a slow connection) and to be used as part of the current ERP, to extend resource access control.
    The project's development stalled, due to lack of time for development.
    Now, I am thinking to continue, but first I will do a revision of the specs, and write a new set, because demands changed...

    I would like to hear from you is: what would you need from such a system?
    What special demands could appear?
    and so on...

    Best regards.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •