jacc question

[julien1]

In JBoss Portal we use jacc as an implementation of the portal security policy. Today how it is done is that one policy context is attached to one resource to secure (one page, one window, etc...).

We did choose that because the portal policy configuration is dynamic and jacc is configured for the lifetime of the deployment (as it is used in J2EE), making policy reconfiguration impossible.

The bad consequence is that it makes the imply of a permission non effective. For instance if we use the FilePermission semantics and our semantic, the permission for a directory that applies to its children will be stored in one context and a FilePermission check on a child resource of the directory will occur in another policy context.

The workaround for that is to make ourself the job of the permission imply job.

Any idea to improve that ?

[starksm64]

There is a PolicyConfiguration linkConfiguration notion that maybe needs to be expanded, or is not implemented correctly for this usecase. Are you linking the child contexts to the parent?

Its not clear that this linking is designed for the type of relationship you are talking about though. If a child context should be picking up its parent context permissions, this is something that could be done when building the child context. You could even have a new permission type called ParentFilePermission that allowed for lazy resolution of the implies check. This permission would only be used if there was no match against the child context for example. The thing you have to be careful of is conflicting permissions. I think if you used the ParentFilePermission notion and only followed it when a context had no matching permissions this should work.

I would want to see some standalone testcases for the types of permissions being generated and the relationships between the contexts. This is an example of an integration usecase for which the unit tests need to be added to jbossas.

[anil.saldhana]

linkConfiguration specifies that the same principle to role mapping should be applied across all policy contexts that comprise an application.

A notion of an application needs to be introduced and all the policy contexts that comprise an application will have the same principle-permission mapping???

In the case of directory and children in the directory, the directory can assume the notion of an application and all the individual files' policy context get linked to the directory policy context.

The spec says that the children policy contexts linked to an application must have the principal-roles mapping, with a transitive and a symmetric relationship......

[julien1]

I thought about using linking, but I looked at the jacc implementation and the link operation leads to a empty implementation so far. By reading the spec and looking at how it is used by EAR/EJB deployment, it looked like it was the only option to use.

There is a PolicyConfiguration linkConfiguration notion that maybe needs to be expanded, or is not implemented correctly for this usecase. Are you linking the child contexts to the parent?

Its not clear that this linking is designed for the type of relationship you are talking about though. If a child context should be picking up its parent context permissions, this is something that could be done when building the child context. You could even have a new permission type called ParentFilePermission that allowed for lazy resolution of the implies check. This permission would only be used if there was no match against the child context for example. The thing you have to be careful of is conflicting permissions. I think if you used the ParentFilePermission notion and only followed it when a context had no matching permissions this should work.

I would want to see some standalone testcases for the types of permissions being generated and the relationships between the contexts. This is an example of an integration usecase for which the unit tests need to be added to jbossas.

[starksm64]

The permissions being added to the policy config can be linked independent of the policy configuration. See the PermissionCollection form of the PolicyConfiguration methods. You need a custom PermissionCollection that understands how to navigate from child to parent when implying a permission.