I'm working with the use case published on http://wso2.com/library/articles/2010/10/using-xacml-fine-grained-authorization-wso2-platform/ and it works well but I need to customize the XACML query with Action, Resource and Subject fields.
When I add the Entitlement Mediator to ESB I am not able to add these arguments (which are stored in properties elements on ESB). How can I specify Action, Resource and Subject to construct the XCAML query before sending to IS?
Thanks in advance,
Joan
In entitlement mediator has call back handler where you can implement a way to pick those Action, Resource and so on. By default handler, picks as following
Resource --> Incoming message "To" soap header
Subject ---> if your proxy service is secured with UT and Basic auth, it would pick the authenticated user name
But you can write your own handler and plug it with entitlement mediator, there are some available handler implementations. You can refer this [1] for more details
[1] http://nallaa.wordpress.com/2013/07/25/entitlement-mediator-with-wso2-enterprise-service-bus-esb/
It is fine to use ESB 4.8.0 it would be release soon. However there is no UI in 4.7.0 to configure them. But you can do it using synapse configuration. Say you want to add new custom call back class. you can add it as follows
Related
I am using Crossbars dynamic authorization to authorize all RPCs in my application.
Is it or will it be possible to access the arguments of the RPC in the authorizer?
It might be possible to solve the issue by utilizing "pattern based registrations". The argument can then be moved into the URI to be examined by the authorizer.
For example the protected resource can register com.example.user.*.delete and when the procedure is called with com.example.user.123.delete - the authorizer will be able to extract the user ID from the URI.
This is documented in the WAMP spec and also in the documentation for Crossbar.io
Accessing the arguments of the RPC is not possible. Dynamic authorization is there to work on the level of the data contained in the configuration, not application payload. If you want to do authorization based on the payload, then this needs to be triggered from the side of the callee.
What's the use of action/reply action for service operation in WCF. So far, what I've understood is; action is used by WSDL to identify the service operation to which the message from the client belongs and in return reply action is used by service operation to identify the caller to which reply message belong --> Please correct me if I am wrong with this!
Now, I want to understand; what's the real use (apart from handling anonymous messages by using aster ix [*]), I mean this could well be handled internally by WCF instead of exposing it to the developer.
Also, why is action and replyaction required at all? I mean, we already have a name property for the service operation to identify the method and when I call Proxy.SomeMethod() then somemethod is already mapped to the Name property and it should be enough to identify the destination method for the message and similarly the replyaction. Please clarify.
Can I please get a simple real world scenario/or link to that to understand Action/ReplyAction in real life.
Many Thanks.
Actions are part of the various SOAP and WS-* specifcations.
So the first point is that this is not something unique to WCF it is a standard part of the specification you need to support if you want to have interoperable web services. They are used for message routing and other message handling functions.
Second, WCF DOES manage these by default. You only need to specify them yourself if you wish to customise or manage them in some other way. E.g. WCF will automatically generate them into the WSDL for you. WCF will also use them by default when it is selecting which operation to invoke for an incoming message. Again, WCF provides extension points to customise this behavior if you require.
I have a universal service hosted on IIS7 that accepts a Message and returns Message ( with Action="*"). This service still publishes meta for the clients.
This metadata is explicitly specified using LocationUrl property in ServiceMetadataBehavior.
We have a requirement that the metadata can change during lifetime of the service, so in essence metadata has a lifetime.
I tried adding IWsdlExportExtension to the service endpoint behavior, but the ExportEndpoint method only gets called once (when the service is loaded first time). Is there a way for me to invalidate the loaded metadata so that anytime there is a call for wsdl using HttpGet, the behavior gets called ?
What you are asking for (changing the published service definition at runtime) is not possible - you need to remove the requirement which specifies that the metadata can change over time.
Once you've published a service, the only reason the service specification should change is because the service has been upgraded.
You should look closer at the business requirement which is making this technical requirement necessary, and try to find another way to satisfy it (perhaps post in programmers.stackexchange). Perhaps you can have multiple services available, and switch between the services over time - but this is a bit of a stab in the dark without knowing the business requirement.
No there is no way. Moreover if you needed you are up to your fully custom solution because this is out of scope of web services. Changing metadata means changing the service itself = its internal logic which always result in restarting the hosting process and publishing new metadata.
I am consuming one java webservice with WCF client.
I want to pass user related information to service in header. I have aleady gone to through thread
How to add a custom header to every WCF calls?
I have implemented IClientMessageInspector interface with BeforeSendRequest() method. Now, I want to pass user related information in SOAP header like Oraganization, which may differ for every user. I have all this information in my ASP.net application, which uses this service.
Is there anyway I can pass user related information to this BeforeSendRequest() method from asp.net session and build Message header before sending any request?
There are few options
Put the information in Session and retrieve it in BeforeSendRequest
Put it in HttpContext.Current.Items and retrieve it in `BeforeSendRequest'
Use Thread Local Storage (http://msdn.microsoft.com/en-us/library/6sby1byh.aspx)
I've got some WCF services (hosted in IIS 6) which use the Enterprise Library (4.0) Validation Application Block. If a client submits a message which fails validation (i.e. gets thrown back in a ValidationFault exception), I'd quite like to be able to log the message XML somewhere (using code, no IIS logs). All the validation happens before the service implementation code kicks in.
I'm sure it's possible to set up some class to get run before the service implementation (presumably this is how the Validation Application Block works), but I can't remember how, or work out exactly what to search for.
Is it possible to create a class and associated configuration that will give me access to either the whole SOAP request message, or at least the message body?
Take a look at using the Policy Injection Application Block...
I'm currently developing an application in which I intercept (using PIAB) all requests incoming to the server and based on the type of request I apply different validation behavior using the VAB.
Here's an article about integrating PIAB with WCF:
http://msdn.microsoft.com/en-us/magazine/cc136759.aspx
You can create different inteception mechanisms such as attributes applied to exposed operations.
You could log the whole WCF Message:
http://msdn.microsoft.com/en-us/library/ms730064.aspx
Or you could combine it with Enterprise Library Logging Application Block.
I found a blog post which seems to do what I want - you create a class that implements IDispatchMessageInspector. In the AfterReceiveRequest method, you have access to the whole incoming message, so can log away. This occurs after authentication, so you also have access to the user name - handy for logging. You can create supporting classes that let you assign this behaviour to services via attributes and/or configuration.
IDispatchMessageInspector also gives you a BeforeSendReply method, so you could log (or alter) your response message.
Now when customers attempt to literally hand-craft SOAP request messages (not even using some kind of DOM object) to our services, we have easy-to-access proof that they are sending rubbish!