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.
Related
I have extracted the authorization token after running my login API successfully. And it can be used within the same thread while I'm configuring different HTTP requests.
But I want to create a separate thread for rest of my APIs and use the authorization token which I extracted already. How can I do it in Jmeter?
According to JMeter Documentation:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads
So you can pass it in 2 ways:
Using __setProperty() function in 1st Thread Group (or thread) to store the value into a JMeter Property and then use __P() function to read it back where required.
Using Inter-Thread Communication Plugin if your logic is more complex
Hope everyone keeping safe,
I am trying to understand some of the abstractions in asp.net core authentication / authorization (and browsing the source code for additional insight).
There is an abstraction called "AuthenticationScheme" which seems to only bring in a ‘name’ property to the actual IAuthenticationHandler (which seems to be is the type that does the work).
I am trying to understand why asp.net has this the scheme abstraction, if the intent is just to give the handler a name, why not just include a name property in the handler's interface definition ?
To allow usage of the handler multiple times at least.
If you make an API that allows JWT Bearer tokens from two identity providers, then you might want to specify the JWT Bearer authentication handler twice.
And since each handler needs a unique name so we can invoke the right one, the developer must define those names.
I am building an app where I use Scribe for all my oauth needs. I create a service API class overriding DefaultApi20 with my end points for authorization and token URLs.
However for Shopify, the authorization URL is dependent on another parameter (Eg: shop name) where the authorization url needs shopname as subdomain. How do I send parameters for this?
I can do the oauth manually constructing the auth url and token but I am looking for a better way to construct sending custom parameters.
Thanks.
We had a similar situation where a variable on the API had to set differently for different users. We did the following:
-Created a custom serviceImpl which extended OAuth10aServiceImpl (may be OAuth20ServiceImpl in your case).
-gave it a method to set the variable on it's api class
-after service is created by your ServiceBuilder lookup the appropriate value and call the setter method of the service.
-continue with normal OAUth token flow
Note that you also need to let the API know to use the custom service class, for example:
#Override
OAuthService createService(OAuthConfig config)
{
return new CustomServiceImpl(this,config)
}
Hope that helps
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
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!