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). 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. 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? > 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? Thank you for your answer, Simon! Regards, Michael
