I'll throw my 2 cents worth in:
How about
interface SecurityService
{
boolean hasPermission (User, String );
boolean hasPermission( User, String, String );
boolean hasPermission( User, String, String, String );
boolean hasPermission( User, String, String, String, String,
String );
}
Where interface user has:
interface User{
String get/set identifier
String get/set password
}
Then it's up to the implementator to decide on what the strings mean in the
SecurityServic. You could have:
SecurityService.hasPermission ( User, "permission", "role", "group")
or SecurityService.hasPermission( User, "permission", role",
"projectgroup", "application")
or SecurityService.hasPermission( User, "group", "permission", "group",
"projectgroup") (if you want to get really screwy )
To avoid confusion we could use SecurityService.isAllowed( User,
String.....) instead of hasPermission....
Have it text based. Simple. That's the way I like it, even I can understand
that. I think 4 string values would be enough, but we could make the
SecurityService have more if we want. If you want to use only
hasPermission(User, String) then all the other methods just map to this one.
I think having it string based allows the most flexibility as we don't have
to use any particular object, except for User.
The implementing security service could test and cast the user object into
whetever they have used, and access their own security objects.
By using the simple User interface its upto the implementor to decide on
whether a unique identifier is a username or a uerid or whatever.
The only drwaback offcourse it that you can't get the compiler to check you
have things in the right order, but that's your problem!
Think simple :-)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
