How: Customer should only be able to change HIS data...

[acjboss]

Hi,
We are implementing a JBoss application, using stateless session beans and a Swing client (used by employees from the intranet).

Now we need to implement a web client to allow the customers themselves to place orders etc from the Internet.
We'll probably use Struts.

The problem is that, as opposed to the swing client, from the web client the user should only access his specific data; A web user may obviously not see or edit other info (customer info, orders etc) than the one "owned" by himself. Customer id is stored in the relation database, and I guess we'll create a table where the web user's user name and password are stored together with the customer id.

On the EJB/EJB-remote-method-level we currently use admin, guest and internetuser roles. But the problem above is how to narrow the permissions within the internetuser role.

I'd appreciate any suggestions (links to articles etc) to how this problem may be approached in the most effective way.

Best regard,
AC

[moraelin]

Basically those roles can not cover issues such "user X owns item Y". The admin/guest/internetuser/whatever roles are for things which apply indiscriminately to a whole group of users and to a whole part of a program. E.g., you can say stuff like "only a project leader can see this page at all", but you can not say stuff like "on this page a project leader may only see the people working on his project, and on that other page he may only see the other resources allocated to his own project".

So, well, yes, you're back to doing the checks in your own code. You will have to store the customer id with those orders, and you will have to check that the id matches the current logged in user everywhere that you access data from an order. It's not even that hard to do.

But it does bring me to a pet peeve of mine, namely that the current state of JAAS and EJB declarative security is just snake oil supposed to look great to managers, not to solve a problem. And I just hate that trend in the computer industry.

I can't think of any project, real of hypothetical, where the declarative security would be enough. Even if you think something as simple as "hey, let's make a simple guestbook/forum for my own homepage", you'll already run into stuff where just having "admin" and "user" groups isn't enough. E.g., what if I want to allow a user to delete their own post, within a certain time limit and/or if there are no answers to it yet? What if I want to allow users to receive private messages, but _only_ ever be able to see the private messages addressed to themselves? Yep, it's back to programmatic security already.

Briefly: most real life case are _not_ squeezable into an "only admins may do this" mold, but are more like "only an admin OR a user which meets this and that condition may do this." And there it's not even like declarative security even saves you one "||" in the if, it's more like: you can't even use it at all, and have to write the whole if anyway.

So why not just stick with programmatic security all the way, from the start? The very few cases where declarative security might save you 2-3 lines of code, are just not worth learning a new API. And definitely not worth having the security stuff split between your normal Java files _and_ the descriptors. It's actually more maintenance overhead, not less.

But on the other hand, the extra buzzword will look great on your resume, and will impress the heck out of a pointy haired boss if you're trying to sell your program to one. Snake oil technology at its finest, really.