This question pertains to OpenAPI 3.0.0
Have a need to specify Create, Read, Update and Delete permissions as pertains to models and properties.
To be specific, some of our permissions are defined on the models/properties and although there is a correlation with the controller method / operations, they are not the same.
This is for internal use to communicate to clients but would still like to know if a pattern exists.
Two options I have considered are:
Add an x-permissions to each applicable Components Object and be done
Define User permissions in a Security Scheme Object and reference them from the appropriate Security Requirement Object
Specs to reference:
Security Requirement Object
Security Scheme Object
Specification Extensions
Related
I am using the Azure API for FHIR service, and I would like to generate a resource with an Id I create on my side. Looking at the docs, it looks like you are supposed to be able to do a PUT request to /, but it doesn't seem to be working. If I do a POST to / and specify my Id, it gets ignored.
In the future, I want it to be able to generate the Ids, but for the "Importing Legacy Data" phase, I want to be able to specify my own Ids to make the linking side of things easier.
Any ideas?
Update
The problem I am trying to avoid is having to push all the data to the FHIR Endpoint and then go over everything again to create the links.
If the server allows an upsert, you would do the PUT to '/[ResourceType]/[id]', not to just '/'.
For example, if you have a Patient with technical id '123', you could do:
PUT [base]/Patient/123
Make sure the Patient resource has its 'id' field set to '123' inside the resource as well. It has to match the id you put on the url.
Another option would be to construct a transaction Bundle, where you can make entries for each resource you want to upsert. You would use the PUT verb and '[ResourceType]/[id]' again for the entry.request details. After constructing the Bundle, you can send it with a POST to the base, so the server knows to process this as a transaction.
Transaction Bundles are also very useful if you have a bunch of resources that are related and reference each other, since the server is required to update all references for new resources inside the Bundle. See http://hl7.org/fhir/http.html#trules for more information about that. Note that not all servers support transactions, just like not all servers allow upserts as Lloyd mentions in his answer.
Servers are not required to allow external systems to assign ids. Many servers won't support 'upsert' as it risks id collisions. Those that do will typically only enable it in certain circumstances. E.g. all ids are required to be UUIDs, so collisions aren't possible; there's only one source and it's synchronizing with the target system, so it 'owns' the id and there can't be collisions.
Some servers may have a configuration ability to turn on 'upsert' capability if it's been determined to be safe to do.
I am creating a MERN(Mongo, Express, React-redux, Node) stack app where I am adding authentication, authorization and access control features. I know how to implement the authentication service but don't know how to implement the authorization and access control. For example: when user login then he will be able to create, edit and delete todo on his dashboard and no one will be able to see or edit that. How can I implement that? Any links, code or help would much be appreciated. Thanks a bunch!
This is a great question. And the answer is long :-) I just replied to a similar question here so you could start reading that.
TL;DR
What you are looking for is called externalized / dynamic authorization management. The formal model is called Attribute-Based Access Control (abac / Wikipedia). It was formalized by the Nat'l Institute of Standards & Technology (NIST).
More in depth
You stated:
When user login then he will be able to create, edit and delete todo on his dashboard and no one will be able to see or edit that.
You need to write a policy using attributes that will allow users to do such things and prevent them from doing other things. If we rewrite your requirement, it becomes:
A user can create, edit, and delete a TODO item on a dashboard they own.
No one can see items on a dashboard they do not own.
Looking at the requirements, you realize you have:
a subject (or user) with their attributes (e.g. role, department...)
an action (e.g. view, edit, delete...)
an object or resource (the "TODO" item) and its container (the dashboard).
This means you can start rewriting your requirement in terms of attributes. This becomes:
A user can do action == "view" on object of type == "TODO" if user.username == object.dashboard.owner
You can then add:
deny all access if object.dashboard.owner != user.username
The language to write such policies is called ALFA (alfa / Wikipedia, the abbreviated language for authorization. It's a standard defined by OASIS XACML.
Once you've defined your policies, you'll need to deploy them, run them, and enforce them. This is where the ABAC architecture kicks in:
Policy Administration Point (PAP): where policies are written
Policy Decision Point (PDP): where policies are run / executed
Policy Enforcement Point (PEP): where policies are enforced - this could be an API gateway, an interceptor...
Policy Information Point (PIP): where additional metadata & attributes can be retrieved
The question then becomes: where do you want to enforce? What does your MERN architecture look like? Do you want to authorize:
in the web UI? (functional authZ)
in the API layer (transactional authZ)
in the data layer (data-centric authZ / filtering)
For instance, do you want to filter data from MongoDB and only show allowed results? Do you want to apply authorization on the API layer? API gateways (e.g. Kong) can help you achieve that with authorization plugins e.g. Axiomatics-Kong.
There are open-source and commercial ABAC implementations and a standards body too (I'm the editor of some of the specs such as the JSON/REST request/response)
A Java Policy Enforcement Point in JSON/REST - open source
AuthZForce - an open-source PDP
Axiomatics - a commercial ABAC platform
While GraphQL mentions security should be delegated to underlying business logic, the nature of GraphQL lends itself very well to security.
In GraphQL the Query can have a resolve method, also each field can have a resolve method. In a way we are traversing the graph, if we provide resolvers for each query and all fields of their results.
Now "Attribute Based Access Control" is gaining popularity with its ways to define security policy across
Subject
Resource
Action
Environment
One way "Attribute Based Access Control" is implemented is, that it modifies the query being fired to only fetch eligible data. This could be done by a wrapper resolver.
Second way "Attribute Based Access Control" can be implement in GraphQL, is to use field level resolvers to decide whether to expose that field or not.
The question I have to the community is what are the various ways to implement "Attribute Based Access Control" in GraphQL, especially leveraging the strengths of GraphQL
Cheers,
Rohit
There are 2 ways ABAC could be used to secure data - be it GraphQL; SQL; HQL... - like you say:
Either you modify the incoming query so that the modified query only retrieves the entitled data. This is for instance how some database proxies work. It intercepts 'SELECT a, b, c FROM t' and converts it into 'SELECT a, b, c FROM t WHERE...' Axiomatics does that with its Data Access Filter.
Or you configure the underlying system so that it only allows access under the right circumstances. We call that provisioning. Years ago, for instance, MySQL had a feature called FGAC - fine-grained access control that could be used to that effect.
The benefit of 1. is that it is unintrusive. It sits in front of the data source and could in principle work for several types of data sources e.g. SQL, GraphQL... The benefit of 2. is that you do not need the proxy component and the configuration is native to the target system.
In any case, yes Graph databases lend themselves really well to ABAC because of the relationship between the different entities. In a way, relational databases have that too but perhaps not as obvious.
I'm investigating ServiceStack's Authorization feature and want to use Couchbase as my data store. I understand there isn't an IUserAuthRepository implementation for Couchbase so I'd have to develop my own, which isn't a problem.
The issue I am having is if I store the built-in UserAuth object as-is, CB it uses the Id field as the document identifier. This is a problem because I believe the identifier should be object type specific, otherwise a separate 'bucket' would be required to prevent conflicting id's across different objects. I don't really want to have lots of buckets unless I have to.
My preference would be to have the document id set to the type of the object plus the object specific identifier.
eg Using Id "UserAuth_1234" or using UserName "UserAuth_MikeGoldsmith"
Is my assumption of trying to re-use a bucket for different application objects valid or should I be thinking about a bucket per object-type / namespace?
Any direction would be welcome, both from Couchbase and ServiceStack enthusiasts.
Thanks
Additional Info
Ok, so from John's answer I will assume my additional property for the object type is valid.
I found this post where Mythz suggests the BootStrapApi example extends the AuthUser with custom properties. However, to me it looks like the AuthUser is persisted twice, first as the AuthUser and again as the User object (both times using the OrmLiteAuthRepository). Am I right?
Essentially, I want to utilise the SS auth feature, but control the POCO object that will be saved into Couchbase. Can someone give some direction if this is possible and if so, what I need to implement / hook into?
I tried implementing a Couchbase version of IUserAuthRepository, however it uses the UseAuth concrete type so I can't use my own object.
I also tried hooking into the OnAuthenticated method of AuthUserSession but at this point the UserAuth POCO will have been persisted using the register IUserAuthRepository.
I'm happy to use the CredentialsAuthProvider as I just want username/password authentication. More could be added later.
Thanks again!
Buckets are loosely analogous to databases in the relational world, so generally they shouldn't be mapped to application objects. I'm not familiar with ServiceStack's auth feature, but your suggestion to use meaningful, prefixed keys seems reasonable and is a common approach for providing document taxonomy.
Keep in mind that in Couchbase, there's no field in the document that's considered an "id" or "key" field. The key used to store the document is available in metadata, but is not part of the JSON document itself. So if you're able to take advantage of views, then you could also store a document with a type attribute and then query by some non-id property. In other words, the key in the key value doesn't have to be the way you retrieve the user auth document.
Also, there are developers who use key prefixing as a way to provide document taxonomy for views, so you're key pattern above would work for that too. My preference is a type property, but that's no more valid than your suggestion.
I've come across the ServiceStack UseCase examples, with one that addresses my Custom Authentication issue directy.
I was able to override the TryAuthenticate method and use my own UserRepository that backs onto Couchbase.
I'm rather new at this, but I've come to understand the security risks of using Breeze to expose an IQueryable<>. Would someone please suggest to me some best practices (or merely some recommendations) for securing an IQueryable collection that's exposed in the JavaScript? Thanks.
I would not expose any data via IQueryable that should nto be sent to the client via a random query. So a projection could be exposed or a DTO.
I'm not sure if this answers your question tho ... What "security risks" are you worried about?
I second this question, too. But to add some specifics along the questions that Ward asked:
In securing queryable services, two traditional issues come to mind:
1) Vertical security: Which items is the currently logged in user (based on user identity or roles) NOT allowed to see in the UI. Those need to be removed from the queryable list. IMO, this can be done as part of the queryable ActionFilter magic by chaining some exclude logic on the returned IQueryable.
2) Horizontal security: Some models contain fields that are not appropriate for the logged in user to see (and/or edit). This is more difficult to handle as it's not a matter of just removing instances from the returned IQueryable. The returned class has a different shape and therefore can be handled either by the json formatter omitting the fields based on security (which AFAIK screws up breeze meta data) or you return a DTO in which case since the DTO doesn't exist in the metadata it's not a full life cycle (updatable) class? (I am asking this not stating it)
I would like to see either built-in support or easy to implement recipes for number 2). Perhaps some sample code to amend the client side metadata to make DTOs work perfectly fine comingled with model objects. The newset VS 2012 SPA templates (in the TodoList app) seem to push DTO variants of the model object both on the queryable and insert/update side. This is similar to the traditional MVC modelviews...
Finally - I'd add a request to auto-handling of the overposting security issue for inserts and updates. This is the reciprocal aspect of 2). Some users should not be able to edit certain fields.