Access Level Design

[ohnnyj]

Hello all:

Can anyone give me some tips, pointer, and just general ideas on how to structure a good access control system for an admin section of a website. There are some that have said a simply access level field in the databse will suffice, but then others recommend a full fledged permissions based system. How would the latter be implemented? I.e. what kind of table fields would you need? This is mostly for a photo upload type of system where users should only be able to upload photos into their own categories and can not access certain portions of the admin site.

Thanks,

John

[oceanmajk]

In your database, just create records that reference the images uploaded to your server by memberID. That way, your members would only have access to view/edit/delete the images that have records associated with their memberID only.

A simple table with the member's info in it, name, email, username, password, etc. can easily be used to limit access to a portion of your site that they can only see what is theres to play with.

[Dr Livingston]

You have users. You also have groups. You assign a user to one or more group(s). Therefore, you usually have one or more actions, or permissions. You assign one or more permissions to each group.

That, in turn, allows your users access to the application. What I do is to pass in a URL such as something like this,

www.sampledomainnamewouldgohereforexample.com?plg=products&act=view&id=12dfk443s

There I take the parameter 'products' as the group, and the parameter 'view', as the action, based on an ID. Authentication takes care of the rest. Fire and forget basically?

[McGruff]

Are you serious? If you pass user groups via GET anyone can set any group they choose.

[ohnnyj]

Are you serious? If you pass user groups via GET anyone can set any group they choose.

That's what I was thinking, if you simply happen to plug in the right id (admin) then all is available.

I can see how the setup of oceanmajk would work and already have that sort of structure built in but was using if for other purposes. I just didn't know if it was a good idea to make a finer grained permission system. Something where you have read/write/delete options on various sections of the site.

[Super Phil]

Are you serious? If you pass user groups via GET anyone can set any group they choose.

I was under the impression that the id related to a specific product? I couldn't believe anyone literate enough to keep up with this forum would have their entire permsision system based on an user id passed through get.

[arborint]

There are some that have said a simply access level field in the databse will suffice, but then others recommend a full fledged permissions based system.

That's because you haven't specified the requirements. You state:

This is mostly for a photo upload type of system where users should only be able to upload photos into their own categories and can not access certain portions of the admin site.

That sounds like access by User ID. That is the simplest access control. But you mention an "admin site" so how many types of administators? If only one then administrative accounts can just ignore the access by User ID rules. The question becomes: how potentially will it become more complex? Do you need groups? Do you need permissions on images and categories? Answer these question and it should be clear what you need.

[Dr Livingston]

Of course I have not lost my head McGruff. I'm not that stupid, so what are you talking about huh? Your on my ignore list anyways, so I don't even know why I'm making the effort to correct the misunderstanding.

There is no security threat in any way, shape or form, as the user is authenticated on each page load regardless. If someone just happens to abuse the URL variables, they're redirected to an error page, and the error and user details are logged.

[McGruff]

You said you were passing the group in the plg var. Is that not so?

I should hope you would make an effort to correct the misunderstanding since bad advice is confusing to those asking questions. This latest example is potentially catastrophic.

[Dr Livingston]

Umm...

If I pass a reference of which group to use via the URl, I take this parameter, and the users ID, and validate this against what group(s) the user is assigned to, to determine if the user has access.

Further, the action to carry out on that group is also verified. Some one could abuse the URL parameters true, but they'd need to know for sure, which group(s) that given user is assigned to, to do anything with it.

If they just use any value, it's caught and dealt with. No system is 100 percent and entirely secure, as there are just too many variables and unknowns. But as developers, what we can do is to do our best to catch breaches when ever they happen.

But I'll add that it's healthy to be paranoid in regards to security. Is that better?

[McGruff]

Let me get this straight. You're passing the user group via GET and this is used along with a user id - the "id" var above, also passed via GET - to assign permissions. Security relies on your belief that no-one will be able to guess another valid user group or id.

The only reason it wouldn't get broken into would be because a hacker might think it too trivial a test of their abilities. From someone who claims to be a professional programmer this is absolutely shocking.

[Dr Livingston]

id=12dfk443s

This is an ID for a product, and a specific product only. It has absolutely nothing to do with any user. The users ID is masked and stored in a SESSION variable. The users ID is masked via MD5 on each page refresh, so the hash changes every time.

From someone who claims to be a professional programmer this is absolutely shocking.

Indeed. If you had to see some of the script that I've had to replace in the past from professional developers, you'd be shocked in more ways that what you are now with my approach.

My clients pay me a lot of cash to develop their software. I wouldn't be in business currently if there were to be any flaws in my software design or development stages McGruff.

[Ryan Wray]

I myself feel confused by Dr. Livingston's example. <strikethroughwouldbeideal>Is id (in the URL) a user id, item id (or action id) or a session id.</strikethroughwouldbeideal> (I didn't see you're above post as I made this one virtually at the same time, I now see it is a product id). Is 'group' related to authorisation or is it do more with a certain category of images.

I think there is a misunderstanding about what you mean, Dr. Livingston.

[Dr Livingston]

Due to the design of my scripts, there is more to the term of 'group', than simply authorisation responsibilities. At the moment, I'm not too keen to go into more detail, but there is an (I suppose it could be called...) Application Controller by the name of the group requested by the user.

All groups regardless are in a hierarchacal structure, which allows me a number of advantages. So I think in your question, it would be to cover both eventuallities, yes?

Is 'group' related to authorisation or is it do more with a certain category of images.

[McGruff]

The users ID is masked and stored in a SESSION variable. The users ID is masked via MD5 on each page refresh, so the hash changes every time.

Sorry I don't understand what you mean. You talk about masking the user id: is the hashed value being returned to the client in some way?

[Dr Livingston]

Nope.

[McGruff]

I was about to ask what is it being masked from but this could go on forever. Your posts raise more questions than they provide answers. This really isn't very helpful to the original poster.

[Dr Livingston]

I may have raised a few more questions, but for what I have posted to this thread, is based on what I have developed. The questions don't have provided answers as I don't want to give out too much.

Originally I was only expression an avenue that I took, that's not to suggest that someone else has to walk down the same road surely.