Hi On Tue, Nov 4, 2008 at 5:14 PM, Michael Frey <[EMAIL PROTECTED]> wrote:
> Hi, > > Simon Laws schrieb: > > > You should be able to do this. For example, > > itest/policy-security-basicauth uses reference and service intents as > > follows.. > > I'm using Apache Tuscany 1.2.1 and there is no such directory. I had > also an look on version 1.3 and 1.3.2 and there is also no such > directory. In 1.2.1 there is in the examples directory a policy which > uses an authentication mechanism (examples/calculator-ws-secure-webapp). Ah. I should have asked what version you're using. This test is only available in trunk. You are right though that samples/calculator-ws-secure-webapp does a very similar thing. > > > The syntax looks a bit different to your quoted example. Instead of > "<binding.ws <http://binding.ws>" the syntax in the policySet element is > "sca:reference/sca:binding.ws" or "sca:service/sca:binding.ws". > > I'm using now constrain="binding.ws" in the policy own definitions.xml > and in the definitions.xml of the application I use > sca:service/sca:binding.ws. It works now. Anyway, thank you for your help! > > > Ok, so does this rely on the clients authenticating in some way? > > No, not really. > > > > This is a bit more tricky. We may not generally have this information > > available. Even if we did I'm not sure you would want to rely on IP type > > information in order to provide QoS type discrimination. I would imagine > > you would want the client to authenticate, using an authentication > > policy, and then base the QoS disrimination based on the authenticated > > client identity. If you are using the Tuscany binding.ws > > There is no need for an authentication. A client makes an service level > agreement with some kind of service level management server. The content > of the service level agreement are quality of service parameters > (service level objectives) like throughput or response time of an web > service offered by an SCA application. The policy is aware of the > agreements and only "put" clients into queues while they have an valid > agreement. How is knowledge of the agreement passed between service and client in a way that means that one client can't pretend to be another? > > > Hm, you mean I should add an authentication mechanism to separate > between the clients. If I enable my policy extension and also add an > authentication mechanism is there a way to access the authentication > data from my own policy extension? Is the token based authentication > mechanism part of Tuscany 1.2.1? Unfortunately some of these things, e.g. the token based security policy, haven't made it into a release yet. Are you set on using 1.2.1? Are you in a position to try things from trunk that are not in a build yet? > > > If you did want to get hold of the client IP info the way we would do it > > is to instigate a new interceptor to pulling out the remote address from > > the http headers in the message context. > > Is there actually a way to add an extra interceptor which is aware of > the clients IP address and can pass it (through the message object) to > the policy interceptor in the invocation chain? We'd have to make a change to the web service binding to pass the context containing the IP information into the tuscany message chain. I can do that but of course that change would only be available in trunk and in our next release. If you want to work on 1.2.1 then it will be possible to construct your policy. However it would be tricky to implement the policy to pass the credentials across the wire and pull them out at the server as I had to make changes to make that work. If you wanted to experiment for a while and were not too concerned with it being a final solution you could construct a service interface with a callback in which case the URI of the callback interface on the client is passed in the tuscany message. You can get it from msg.from.parameters.callbackReference.uri. This is not though a generic solution and only works for services with callback interfaces. If you can go up to 1.3.2 we may be able to get the token policy working on that release. This would still involve you compiling things from trunk so it may be easier just to start from trunk in the first place. Sorry this is a bit of a pain at the moment but you just happen to find us in the middle of trying to make what you need work;-) > > > Thank you for your answer, Simon! > > Regards, > Michael >
