I will do a page on it, this a an hard and easy at the same time. Meaning once you've grabbed it's simple. Though I will try to explain it here and maybe if I can teach you how it works, it will do the paper ;-)
First you have to understand what is a security rule, it is defined by an ID, 2 regular expressions and one Level. The regular expression have the form : reg1 + ":" + reg2 + ":" + reg3
The first one is called "component match" the second one "instance match"
So here is an example of rule :
Now the rules are organized in an XML files. Each row defines a rule, so you have a list of rules. The list concept is important because rules are tested in the order defined by the list.
So now on the process of security checks. Each component in nukes willing to check some security will call the Core module to ask him if a user can do something or whatever.
you have call like :
boolean canAdd = secAuthAction("mycomponent::", "a:b:", ADD);
On such a call, the core module does :
1.get all the rules associed to the group of the current user and keep the order.
2.set level variable to invalid
2.for each rule
3.if the component match matches the component test and if the same applies for the instance then set level to the rule level and break the foreach
4.return true if the level is greater or equals than the level parameter
in the trivial case here, if the user is an admin, the rule I wrote will be considered, and since the component match and instance match will match everything because they are expression like ".*:.*:.*" therefore the ADMIN level will be granted to the user admin and he will be able to do everything in the system.
am I clear enough ?
Are there plans to get rid of all of this "crap" and integrate it into java security model ?
I understand that this is a port from postnuke but postnuke was developed for the poor php environment and not our powerfull Java platform ...
hahaha, very fun, what do you propose ?
thanks for your explanation on permissions. I understand the basic concepts of what you were saying but was wondering if you could provide another couple of examples.
I would particularly like an example of an xml element to set the security permissions on the htmlModule.
ie. like below, but to give a group access to be able to edit the html pages. I have tried to set the following xml level attribute to attribute, but I still can't get the edit html functionality working for that group.
Also, is it possible to restrict a group to be only able to access pages with id's of a certain type (eg. id's that start with 'H'). I read a little of the htmlModule source and it seemed to suggest that it was possible.
thanks very much
whoops, that should have been, "i tried to set the level attibute to ADMIN" not "i tried to set the level attibute to attribute"
Well, you know, something like "principals" ? "roles" ? "LoginModule" ? You ever heard something about those strange things ?
yes, I did, the previous forum try (last year) was making use of jaas.
we consider inject jaas into nukes for security. however jaas does not tell you how the access control must be done. what you are criticizing is that model.
jaas give you means to authenticate and authorize. it is possible to take the current model and use jaas for authentication through login modules and authorization with subject.doAs stuff.
I do not agree with that. I believe you can use security policy (java.security.*) machinery and checkPermission sort of things to mimic the jboss-nuke security model toghether with JAAS auth for authenticating principals.
I hate this wheel reinveinventig sort of things...
As I've already written: I know the current architecture is due most by inheritance from PostNuke... but IMHO this can be changed and a better integration and uniformity will result from adopting java security models: you don't have to understand how jbossnuke security works because it would work like any other java app security thing
my opinion is : at the end of the day, you must have a set of rules that will define how permissions maps on what principal (in jaas land).
for instance in j2ee security you define the roles on an EJB per method, this is one way to do it, what nukes does with the rules is another one.
for now, the security does not use jaas but it could and at the same time keep the same definition of rules we are using in nukes.
in every case, this is access control based on list, nukes use its own format because this is convenient and jaas use the policy file that has the same semantics.
I agree with you that using jaas would be a plus and we will try in the future to do that as soon as someone wants to do it (perhaps you ?).
I'd be very proud and happy of helping with it.
I don't have much spare time (as one can guess from the frequency of my messages on this forum...) but if I can be useful I will try my best.