I'm currently using istio 1.4 and had enabled a Policy to check jwt.
I enabled an AuthorizationPolicy which have that rule:
rules
- to:
- operation:
methods: ["GET"]
paths: [
"/render/checkout"
]
when:
- key: request.auth.claims[roles]
values: ["USER"]
When I hit that path with my jwt, every thing works great. The problem is when I hit the same url with a query string parameter for example /render/checkout?sort=asc, I get a RBAC: access denied.
to bypass this, I ended up adding the path including the question mark and a wildcard:
paths: [
"/render/checkout", "/render/checkout?*"
]
but having a lot of paths and a lot of microservices, I feel that should not happen as it happens because it's very repetitive and error prone.
I know that there's already an issue on github about supporting regex in paths, but currently :
Can I avoid doubling each of my paths, one without query string parameters and the second with the query string parameters?
There is a github issue where someone asked same question few days ago which leads us to github issue you add.
Specially this part of github member answer #GODBS.
There is no other way to exclude paths for JWT then to use an Authorization Policy which does not allow regex.
Can I avoid doubling each of my paths, one without query string parameters and the second with the query string parameters?
So as far as I understand currently there is no other way to make it work. The workaround for now is to add another paths, like you did.
I assume they will add it in the future, the question here is how long will it take.
Related
I have some code to retrieve a list of files from a repository (using REST API v3) and it worked great for many cases, but now I've hit a problem where it didn't work. Looking into this, I found that one of the elements of the response had this:
{
"mode": "160000",
"path": "folderA/folderB/folderC",
"sha": "84419db012d987a1705eea28055b278c17411a93",
"type": "commit"
}
If I look at that path using the browser, the folder is shown as:
- so after some confusion and embarrassement, I looked at things and concluded this must be a submodule (indeed it is mentioned in /.gitmodules.
I wonder how to best deal with that when I want to retrieve everything: currently my plan is to use path-entry to find a matching [submodule "path"] and then retrieve the tree from the repo using ther url from .gitmodules and sha from the response that I quoted. There is a path in .gitmodules, too - I guess that's just redundant? (Would be grateful for any other comments and suggestions. Maybe there is an easier approach to get thinghs?)
Also, I did not find doc about this - so is submodule the only reason for having commit in the respone, or could there be other cases to consider?
Update: it worked as I described! But I'm really concerned I might be hit by other unexpected items in the reply, so the question is really about documentation regarding the items in a response to querying the tress-API.
I have a route definition in function.json: entity/{paramName}
When I make a GET request: http://localhost:7071/api/entity/50043e-315
In context.bindingData.paramName I get surprising 5.0043e-311, while context.req.params.paramName contains 50043e-315.
I noticed that here both ways of reading can be used; and here the same is meant, though the links are dead by now, while the example here mentions only context.bindingData.
Question: What is more preferable? And what is the difference?
I believe the problem here is that the somewhere (if I were to make a guess, here) the param is being parsed as a double before being stored as binding data. But when fetching it from the request object, it is fetched as a string from the URL directly. Hence the difference.
I believe there are only a few cases where this might happen and this is one of them.
I'm trying to write a step that will match the following steps that are similar and capture parameters:
Step1: And I delete the filter(s) using the "UI"
Step2: Then I delete the filter(s) using the "API" for "doc-browser" context
Step3: I delete the filter(s) using the "API" for "doc-browser" context with user "file_user2"
I don't want to create 3 separate steps, they all start with I delete the filter using the #{arg} and the last 2 just extend on that.
I thought this was going to accomplish it:
And(/^I delete the filter\(s\) using the "([^"]*)"(?: for "([^"]*)" context| with user "([^"]*)")?/) do |delete_method, context, user|
case delete_method
when 'API'
if user.nil?
SearchFilters.new.delete_global_local_filters(delete_method, api_context_val: context)
else
SearchFilters.new.delete_global_local_filters(delete_method, { api_context_val: context, username: user })
end
when 'UI'
SearchFilters.new.delete_global_local_filters(delete_method, filter_name: #filter_name)
end
end
However, I'm not capturing my username.
Is it possible to accomplish having one step definition that captures all 3 variations and still captures my arguments?
Just duplicating my mailing list answer in case anyone else is interested in this question.
I understand you don't want to use three different steps, but in this case you really should because
The implementation of each step is a clear one liner, so you are removing a case statement.
The regex for this step is horrible and you will be removing that
Each individual step provides the opportunity to simplify the parameters being passed, you have 2 API and one UI paramter which can just be removed entirely (if I understand the code correctly you can remove all the params and regexs)
This is a clear case where a little bit of repetition is a price well worth paying for a simpler implementation.
Reducing the number of step definitions by using regex's and params is often an anti-pattern.
All best
Andrew
I am deploying FIWARE security GEs (i.e., Wilma, AuthzForce, Keyrock) in my computer. Security level 2 (Basic Authorization) is working well, but now I need security level 3 (Advanced Authorization) using XACML.
Long story short, I want a tutorial of implementation security level 3. However, as far as I know, any tutorial or document about security level 3 does not exist.
For now, I create my policy with PAP's API, and change 'custom_policy' option in config.js from 'undefined' to 'policy.js'. And then I create 'policy.js' file into 'PEP/policies', but don't change anything compared with its template file because I don't know what this code does exactly. I think I should make XACML Request form using 'xml' variable. But in my case, PEP gives me the error when I make the XACML Request using 'xml' variable, and return this variable. Here is my error of PEP:
Error: Root - Error in AZF communication <?xml version="1.0" encoding="UTF-8" standalone="yes"?><error xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/S" xmlns:ns2="http://www.w3.org/2005/Atom" xmlns:ns3="http://authzforce.github.io/core/xmlns/pdp/5.0" xmlns:ns4="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6"><message>Invalid parameters: cvc-elt.1: Cannot find the declaration of element 'Request'.</message></error>
And here is my 'getPolicy' code (XACML Request) in policy.js. I just made very simple request whether response is permit or not because I'm not sure what I'm doing at that time.:
exports.getPolicy = function (roles, req, app_id) {
var xml = xmlBuilder.create('Request', {
'xmlns': 'urn:oasis:names:tc:xacml:3.0:core:schema:wd-17',
'CombinedDecision': 'false',
'ReturnPolicyIdList': 'false'})
.ele('Attributes', {
'Category': 'urn:oasis:names:tc:xacml:1.0:subject-category:access-subject'});
So, anyone can give me any information about implementation of security level 3?
Upgrade to Wilma 6.2 (bug fixing).
Reuse the code from lib/azf.js which is known to work, and adapt the Request content to your needs. The variable is wrongly called XACMLPolicy there, but don't be mistaken, this is an actual XACML Request. This is using xml2json package to convert the JSON to XML, whereas in your code you seem to use a different one, xmlbuilder maybe? You didn't paste the full code - where does this xmlBuilder variable come from? - so I'm just guessing.
If you are indeed using xmlbuilder package and want to stick with it, I notice that in the example using namespaces, the xmlns attribute is put in a different way:
var xmlBuilder = require('xmlbuilder');
var xml = xmlBuilder.create('Request', { encoding: 'utf-8' })
.att('xmlns', 'urn:oasis:names:tc:xacml:3.0:core:schema:wd-17')
.att('CombinedDecision': 'false')
.att('ReturnPolicyIdList': 'false')
.ele('Attributes', {'Category': 'urn:oasis:names:tc:xacml:1.0:subject-category:access-subject'});
Maybe this makes a difference, I didn't check.
Also feel free to create an issue with your question on Wilma's github to get help from the dev team. (I am not one of them but we've worked together for AuthzForce integration.)
The error you are getting is really
Invalid parameters: cvc-elt.1: Cannot find the declaration of element
'Request'.
This is a simple XML validation issue. You need to make sure that the XACML request you send contains the right namespace declaration.
You'll see there is another question on this topic here.
Can you paste your XACML request so we can tell whether it is valid?
Here is below my code of route:-
app.get('/server/lead/get/:id?', leadCtrl.get);
app.get('/server/lead/filter/:filterQuery', leadCtrl.get);
As you see above i am using different route to access same controller method leadCtrl.get.
Now, i want something like route app.get('/server/lead/get/:id?:filter?', leadCtrl.get);. So, i can get params either req.params.id or req.params.filter but only one at a time.
What you asked in the question is not possible in the form that you describe it.
Now, i want something like route
app.get('/server/lead/get/:id?:filter?', leadCtrl.get);. So, i can get
params either req.params.id or req.params.filter but only one at a
time.
Your router would have no way to differentiate those two parameters. If it got a request to /server/lead/get/X then what is X? A filter or an ID?
Your options
You have few solutions here:
You can either keep using two routes like you did before.
You can use a common parameter for both cases as Robert explained in the comments.
Or you can use what seems to me the perfect solution for your use case - named query parameters - just use a route /server/lead/get and use query parameters to pass id and the filter.
Example URLs:
/server/lead/get?id=xxx
/server/lead/get?filterQuery=xxx
You will only have to make sure in your handler that only one of those two are set at a time with something like:
if (req.query.id && req.query.filterQuery) {
// respond with error
}
You can even mix the two if you have app.get('/server/lead/get/:id?') route you can have the id in the route and filterQuery as a query parameter. Now the URLs would be:
/server/lead/get/xxx (for id)
/server/lead/get?filterQuery=xxx (for filter)
For more info see: http://expressjs.com/en/api.html#req.query
Better way
If you follow some REST conventions then you can use:
app.get('/server/lead/:id') for one object with id (not optional)
app.get('/server/lead') for a list of objects (with optional filterQuery passed as a query parameter)
That way you would always know that when you access:
/server/lead/xxx - then it's one object with ID = xxx
/server/lead - then it's a list of any objects
/server/lead?filterQuery=xxx - then it's a list of objects that match the query
If you follow the REST conventions for things like this instead of inventing your own, it would be much easier for you to design the routes and handlers, and it would be much easier for other people to use your system.
You may also want to use plural /server/leads instead of /server/lead which is common with REST. That way it will be more obvious that leads is a list and leads/id is one of its elements.
For more info see:
https://en.wikipedia.org/wiki/Representational_state_transfer
http://www.restapitutorial.com/lessons/whatisrest.html
https://spring.io/understanding/REST
You have to realize that the following two routes match exactly the same:
app.get('/server/lead/get/:id?', leadCtrl.get);
app.get('/server/lead/get/:filter?', leadCtrl.get);
Express doesn't care about how you name the placeholders, so any requests for /server/lead/get/SOMEVALUE will always match the first (the one with :id).
You can add a distinction yourself, by only allowing a parameter to match a particular regular expression. From your code, it looks like :id should match MongoDB ObjectId's, so you can create a specific match for those:
app.get('/server/lead/get/:id([a-fA-F0-9]{24})?', leadCtrl.get);
If SOMEVALUE matches an ObjectId, it will call leadCtrl.get and populate req.params.id. If you also add another router for "the rest", you can also cover the req.params.filter case:
app.get('/server/lead/get/:filter?', leadCtrl.get);
As an aside: you're saying that you're passing JSON to the "filter" routes, in the URL. I would strongly suggest using a POST route for that, and post the JSON as request body content.