Hi
Sorry that this is a bit long.
I'm looking to port a few more policy models over from 1.x and tidy
what we already have. So the question comes about how to organize
them. To a certain extent this will vary from policy to policy but, if
nothing else, we need to get our approach to modeling security policy
sorted out as we already have a few models floating about and it needs
to make sense from the point of view of the user/creator of the
resulting policy sets. Also there seems to be some extra layers of
extensibility, e.g. around LDAP, that looks like it could do with
rationalizing (it's a little difficult to work out which parts of this
are specific to the http binding and which are generic).
policy-logging (we could rename or split out policy-logging-jdk but
not an emergency)
policy-transaction
policy-transaction-runtime (we don't have a separate runtime module at
the moment)
policy-security
http
basic (rename/merge the current authentication.basic model and
the 1.x policy-security-http/authentication model)
ssl (rename the 1.x policy-scurity-http/confidentiality model.
bindings specific policy can apply it appropriately)
We don't currently model ws security policy directly but expect to
find it within wspolicy which is pushed directly into Axis2/Rampart.
Don't think we need to bring jsr250/indentity/jaas in just yet.
Need to work up some coherent authentication/authorization scenarios.
When we do some of this is Java specific so we could group them
java
jaas
jsr250
identity
policy-wspolicy
the ws policy model that collects other policy expressions
(models). Need to make the intersection part work.
policy-reliability (not required yet as we don't have any implementation)
The majority of the code that is separate from
bindings/implementations will just be models. There are exceptions
where generic runtimes come into play such as logging and transaction.
We need to review what's left and put it in the right places.
To prove that we have this right we need to understand the intents,
policy sets and the resulting interceptor chains, for example, [1].
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy+Implementation
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
