Hi Dan If you don't mind I won't reply inline, I'm concerned that it'll be difficult to read it.
>> Another thing I'd like to avoid is to have some religious debate leading >> nowhere. >> > I really don't believe this is hypothetical or religious at all. I agree that the security considerations are important. It just seemed to me yesterday that the fact the information could be leaked was linked to the suggestion to use polices. Possibly I was in a defensive mood :-). In context of the WS-SecurityPolicy work, I suggested two possible approaches, use polices to keep both public and private stuff (to be stripped off at publication time) or use policies for the public stuff only and features for the private stuff. The concern was expressed that the info could be leaked in the former case, which is fair enough, but I do not think it affects the general idea of when to use polices as opposed to features, rather it's a lower-level concern. Not sure why I used the "religious" term though, I just wanted to avoid a head-on "policies are just better than features and vice versa" debate. > Imagine I'm writing a GUI for CXF which configures the security for my > services. As a CXF integrator, I don't want to have to generate policies > to be able to configure a service. Features are much nicer to use. "new > Feature().setFoo(bar);" I think I agree. I don't see though what it's to do with the issue being discussed, I didn't advocate to generate the policies. But here's another thing. Imagine a design tool consuming a service WSDL (in fact it does not have to be a WSDL), but for the simplicity sake lets use WSDL. If this WSDL has policies attached then the design tool can easily recognize the policies associated with a given endpoint, operation, message, binding, ask a user for additional questions, or, may be even generate the code you shown in the example. Now, the policies do not have to be explicitly attached to the WSDL, a CXF external policy attachment mechanism Andrea did can be used to annotate the published WSDL, polices can live outside of WSDL with the latter being unaware of them. > I would like to be able to configure CXF specific configuration items > (like key info) via a feature. Policies can then be attached. So are we in agreement or am I misunderstanding ? Do you agree that the private stuff goes into features and the public stuff goes into policies, when dealing with WS-SecurityPolices for ex ? This is one of the approaches which people seem to agree upon. I just don't quite understand what you mean by "Policies can then be attached". Do you mean "information in features and policies will be merged" to provide a unified view of the configuration info to the WS-SX engine or something similar ? This approach will work, it will be just more complicated but it will work. That said, I'd still like CXF to support "the private-info inside a policy" approach, it might make design tools happier. But as I said, it's not something which concerns me much at the moment. > > I see policies and configuration of the other bits as two seperate > processes. For instance, you may have a policy which you apply to all > your services. But the key information may differ on each one. This makes total sense to me. So are we in agreement :-) ? >> * how can one satisfy a user's desire to attach capabilities to endpoints, >> operations, and bindings using features >> > Yeah, thats what Policy is for. Are you suggesting that users are going > to have different key information for different operations? I can > certainly see bindings/endpoints - and you can apply features at that level. With WS-Policy one can apply seperate (WS-SecurityPolicy) policies to messages, portType itself, portType/operations, binding itself, binding/operations, etc. They get then merged into effective policies for different policy subjects like endpoints. I didn't mean a seperate keyinfo per the operation, and as I said above, agreed, using features to specify, say, per-service key-info details, passwords, etc sounds good. > Speaking of the client: are you suggesting the client has to take a > policy from a service, add in a bunch of extra expressions for key info > and the like, and then deploy? Thats a hell of a lot of work. Thats what > features are for: to supply configuration which is orthogonal to Policy. I just mean that both Policy and features will contribute to providing all the information a WS-SX engine will need. I'm somewhat uncomfortable about the 'orthogonal' term but I think I see what you mean and I agree. I see policies serving two goals : providing info to the consumers and, as a positive side effect, providing the configuration to the providers and as such they play together with other mechanisms like features. > Who's looking at WS-Pol as a configuration option only here? I didn't > think anyone was. This is great. It's a good message. > So to summarize: we should use features for information which is not > useful for the client and for stuff which should not be public beyond the > local service. +1. Agreed... >Because: > 1. It makes API configuration of the service easier. No need to generate > policy documents by hand. Don't understand. I've seen your example but I don't see what it's to do with supportng WS-SecurityPolicy (which are policy expressions). Can you explain again ? > 2. Security considerations - Policy files are not easily tracked and > will leak IMO I'd not go that far. What about config files, what about trust to the runtime itself ? Is it written in stone it's all safe and bullet-proof ? But I'm ok with accepting this message for now. > 3. Configuration readability - WS-SecPol files are quite verbose/sticky. > As Fred said: "Im less inclined to use WS-SecurityPolicy as a > configuration mechanism, at least exclusively so. It's not really > designed to be human-readable, despite the fact that it's written in > XML, and XML is supposed to be human-readable, etc etc." Hmm... I'm totaly lost again. I agree the verbosity is there. What does 'sticky' mean in this context ? So what does it mean to you to support a WS-SecurityPolicy ? > 4. Separation of concerns: Policy and configuration are two separate > processes, often done at different stages. They also have different > levels of reusability. Hmm...You're probably now referring to those SOA architects applying their polices and seeing the configuration being generated ? Yes ? What is it to do with supporting a WS-SecurityPolicy ? Having WS-SecurityPolicy polices attached to say a WSDL plays 3 roles : providing info to design tools, providing info to client runtimes for the intersection purposes, and configuring the provider's runtime. What do you mean by diffent stages ? If you're talking about SOA architects then in their world no WS-SecurityPolicy may exist, WS-SecurityPolicy is a lower-level concept, product/WS-* specifc, etc > > I'm not saying we couldn't also support policy expressions for > configuration, but I think the use case for it is limited. Again, as > Fred said: "I agree that in some small percentage of cases, we need to > support configuration of WS-SecurityPolicy directly, and at a low level, > but these cases fall below the 20% bar, and can certainly be exposed > through low-level config." Totally lost. I start feeling that when saying "we want to support WS-SecurityPolicy" you guys mean to look at a WS-SecurityPolicy spec, see what is possible to configure using those policy expressions and then just translate it all into cxf features and that is it... Am I right ? If yes, then CXF won't support WS-SecurityPolicy ever, CXF will support WS-Security. Do you see the difference ? Or am I totally off-tack ? > > Of the above items, I will admit that 3/4 are potentially overcomeable > but I would rank #1 & #2 as very important issues which kill the idea of > configuring everything in Policy for me. We could also potentially use a > feature to generate policy, but that would be a PITA IMO. It'd probably > just be easier to interact with the WS-SX engine directly. I don't understand it, sorry. Please clarify points 1, 3, and 4 again. Thanks, Sergey ----- Original Message ----- From: "Dan Diephouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, September 25, 2007 3:38 PM Subject: Re: WS-SX > Sergey Beryozkin wrote: >> -----Original Message----- >> From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] >> Sent: 24 September 2007 21:31 >> To: [email protected] >> Subject: RE: WS-SX >> >> I think we're over-blowing the problem a bit. Lets not get sidetracked into >> hypothetical discussions on how dangerous it is to put a private stuff into >> policies. Rather lets come up with a set of practical guidelines on when to >> use policies and features. >> Another thing I'd like to avoid is to have some religious debate leading >> nowhere. >> > I really don't believe this is hypothetical or religious at all. >> Dan, you said you wanted to support WS-SecurityPolicy because it was so >> important for the enterprise. Now you're also saying that using features is >> so much better from an API perspective. >> >> I personally don't understand what is your position. I'm just confused. Can >> you please clarify? >> > Imagine I'm writing a GUI for CXF which configures the security for my > services. As a CXF integrator, I don't want to have to generate policies > to be able to configure a service. Features are much nicer to use. "new > Feature().setFoo(bar);" >> Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't >> think it makes any sense but I'd you to explain please. >> > I would like to be able to configure CXF specific configuration items > (like key info) via a feature. Policies can then be attached. > > I see policies and configuration of the other bits as two seperate > processes. For instance, you may have a policy which you apply to all > your services. But the key information may differ on each one. >> Can you explain please what you mean by saying it's so much harder to set up >> a service using a policy ? >> > See above. >> I'd also like to suggest you to think of the following : >> >> * how can one satisfy a user's desire to attach capabilities to endpoints, >> operations, and bindings using features >> > Yeah, thats what Policy is for. Are you suggesting that users are going > to have different key information for different operations? I can > certainly see bindings/endpoints - and you can apply features at that level. >> * how can a client to avoid doing duplications like enabling MTOM on the >> client side when using features >> > I don't understand this question - if the client encounters an MTOM > policy expression, it can just enable it. No feature needed. >> * how can a client perform intersection of capabilities using features >> > Eh? I'm not suggesting we rip out policy all together. > > Speaking of the client: are you suggesting the client has to take a > policy from a service, add in a bunch of extra expressions for key info > and the like, and then deploy? Thats a hell of a lot of work. Thats what > features are for: to supply configuration which is orthogonal to Policy. >> Or yes, one more thing. >> >> How can one express 'or' combination using features, that is how one can do >> multiple alternatives, something one can easily do with policies : >> >> <Policy> >> <All> >> </All> >> <All> >> </All> >> </Policy> >> >> Alternatives are targeted at a consumer. Multiple consumers can choose their >> own alternatives and a provider will ensure it supports all the consumers. >> Consumers may also have their policies on which case they'll do the >> intersection. >> >> This clearly shows that WS-Policy is not about configuration only. Looking >> at a WS-Policy language as the configuration option only is not correct. >> I don't want push the message that using policies is the only true way to >> go. I'd just like us to agree on a policy (:-)) when polices should be >> applied. >> > Who's looking at WS-Pol as a configuration option only here? I didn't > think anyone was. > > So to summarize: we should use features for information which is not > useful for the client and for stuff which should not be public beyond > the local service. Because: > 1. It makes API configuration of the service easier. No need to generate > policy documents by hand. > 2. Security considerations - Policy files are not easily tracked and > will leak IMO > 3. Configuration readability - WS-SecPol files are quite verbose/sticky. > As Fred said: "Im less inclined to use WS-SecurityPolicy as a > configuration mechanism, at least exclusively so. It's not really > designed to be human-readable, despite the fact that it's written in > XML, and XML is supposed to be human-readable, etc etc." > 4. Separation of concerns: Policy and configuration are two separate > processes, often done at different stages. They also have different > levels of reusability. > > I'm not saying we couldn't also support policy expressions for > configuration, but I think the use case for it is limited. Again, as > Fred said: "I agree that in some small percentage of cases, we need to > support configuration of WS-SecurityPolicy directly, and at a low level, > but these cases fall below the 20% bar, and can certainly be exposed > through low-level config." > > Of the above items, I will admit that 3/4 are potentially overcomeable > but I would rank #1 & #2 as very important issues which kill the idea of > configuring everything in Policy for me. We could also potentially use a > feature to generate policy, but that would be a PITA IMO. It'd probably > just be easier to interact with the WS-SX engine directly. > > - Dan > > -- > Dan Diephouse > MuleSource > http://mulesource.com | http://netzooid.com/blog ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
