Is it possible to show that some collections can be accessed only by user which has same permissions/roles?
For example how it is in https://api.slack.com/methods/channels.create
Expected scopes:
channels:write read
The concept of access permissions exists at the layer of business
logic and is not intrinsic to GraphQL itself. I think your best bet
here may be documenting any constraints that in description fields in
the schema, where they will then be shown in the GraphiQL
documentation explorer.
https://github.com/graphql/graphiql/issues/564
Related
I have an API in Postman that has defined JSON schemas for every request\response.
I also have a collection of tests that i use for testing this API.
But I don't know how to connect these two substances(things)
I have been searching for a solution for quite a while now and havent found an example set-up or a tutorial how? instead of creating a variable with actual schema in my test collection, I want to reuse already existing schema from API by $ref or some other link method.
This is my first question here, writing it just cause i haven't found a proper answer but functionality that i seek sounds really basic and logical.
Update from Valentin Despa:
"Please note that the API definition is written in a specification like Open API (or similar). It is not the same as the JSON schema which refers to the response body only."
So we can't validate response using that schema.
How do you implement authorization for a list of resources?
All docs I see are based on IAuthorizationService and the AuthorizeAsync methods. But this, only applies to one resource.
Should I be retrieving all resources and then imperatively check if the user has access or not using the AuthorizeAsync method of the IAuthorizationService? This seems very ackward, slow and inneficient.
How would you do this?
I have implemented this in few of my projects and aside from fetching all resources from the database and then executing AuthorizeAsync on each of them there is not much that you can do (so far as I know).
In some cases you can have mapping table in the database that stores resourceId/userId and check according to that. It is easier to fetch items that way without executing AuthorizeAsync on each, but it is not applicable in each scenario...
There are a few questions on this subject (such as https://github.com/dotnet/AspNetCore.Docs/issues/10244) but no solution.
I would like to use GraphiQL docs to document my GraphQL API. The out-of-the-box version already looks pretty useful, however I would like to enrich it by the information about permissions.
My imagination is that in this
there will be another section, i.e. "Permissions", with some description of the permissions.
My question: is this the way to do it? If not, how can one express permissions in the GraphiQL Docs? And if this could be the way, is there any tool capable of doing this?
What's shown in GraphiQL (or similar tools like GraphQL Playground, Altair, etc.) is limited to what can be returned through introspection of the schema, which is limited by what the spec specifies. You can add descriptions to types, fields, arguments, enum values and directives. A description for the schema itself is in the works.
At best, you could add a description to your field specifying the permissions. You can use markdown if you want to jazz it up.
What are some of the well known products/services around Authorization (RBAC and ABAC) that implement standards like XACML?
Our customers are organizations.
Each organization would be given 3 default roles (after onboarding)
but also have the capability to create more roles
Roles define level of access on the under lying resources (not just the API level (which is via scopes) but at the resource level)
Another use case is that of superuser who can act across organizations and perform any action.
Please share your thoughts on if these use cases can be solved (and the ease) in the product or service you recommend. thanks.
You can find a list of XACML implementations on the dedicated Wikipedia page. To address your use case which is very RBAC-oriented, I would use the RBAC Profile of XACML, so make sure the implementation you choose supports that.
cdan is right. Start with the Wikipedia page for XACML (and the ones for ABAC and ALFA) which list implementations but also use cases. You have quite a broad range of commercial and open-source alternatives.
In ABAC, you tend to try to write authorization policies independently of the underlying technology. This means that whether access is via APIs or via a webpage should not matter in defining the authorization.
The key questions you want to ask yourself are:
Are there relationships in authorizations? E.g.
a user with role='manager' can do action = 'view' on object = 'record' if object.organization == user.organization.
Do I care about auditing the authorization? Do I need to prove my compliance?
Do I need context and runtime attributes e.g. time and location?
Do I need to apply the same authorization logic across multiple apps, APIs, and data?
Do I need to regularly update my authorizations?
If you answered Yes to one or more of the above questions, you likely need ABAC.
I came across many different models for the Access Control in a system. When implementing an Access Control model in any system, we usually hard code the rules/rights in the database(considering an RDBMS) by creating separate tables for the Access Control. Also, these rules/rights can be stored in an XML database.
I would like to know what is the difference between storing the rules on RDBMS and on an XML database? Also, when should we use XACML for implementing an Access Control model in a system? I mean, how one can decide whether one should hardcode the rules/rights in the database or one should use XACML policy language?
Thanks.
Disclaimer: I work for Axiomatics, a vendor implementation of XACML
Storing authorization logic if you go your own way could be done either in the RDBMS or in an XML database. It doesn't matter. I doubt that XML brings you any added capabilities.
Now, if you want an authorization system that can cater for RDBMS systems and other types of applications too (CRM, .NET, Java...) then you want to use a solution that is agnostic of the type of application it protects. That's the goal of XACML, the eXtensible Access Control Markup Language.
XACML provides attribute-based, policy-based access control (ABAC and PBAC). This gives you the ability to write extremely expressive authorization policies and managed them centrally in a single repository. A central authorization engine (called Policy Decision Point or PDP) will then serve decisions to your different applications.
As Bell points out, the minimum set of attributes you will need is typically attributes about the user (Subject), the resource, and the action. XACML also lets you add environment attributes. This means you can write the following type of policy:
Doctors can view the medical records of patients they are assigned to.
Doctors describes the user / subject
view describes the action
medical records describes the targeted resource
of patients describes the targeted resource too. It's metadata about the resource
they are assigned to is an interesting case. It's an attribute that defines the relationship between the doctor and the patient. In ABAC, this gets implemented as doctor.id==patient.assignedDoctorId. This is one of the key benefits of using XACML.
Benefits of XACML include:
- the ability to externalize the authorization logic as mentioned by Bell
- the ability to update authorization logic without going through a development/deployment lifecycle
- the ability to have fine-grained authorization implemented the same way for many different applications
- the ability to have visibility and audits on the authorization logic
HTH
The two are not mutually exclusive.
An XACML policy describes how to translate a set of attributes about an attempted action into a permitted/denied decision. At minimum the attributes would be who the user is (Subject), what they are trying to do (Action) and what they are trying to do it to (Object). Information such as time, the source of the request and many others can be added.
The attributes of the user and the object will still have to be stored in the database. If you are grouping users or objects to simplify administration or to simplify defining access control rules then you're going to have to manage all of that in the database to. All that data will then need to be passed to the XACML Policy Decision Point to return the permit/deny decision.
The advantage of using XACML to define these rules, rather than writing your own decision logic for the rules defined in the database, is that the assessment of the rules can be handed off to an external application. Using a mature, tested XACML implementation (there are open source options) will avoid you making any mistakes in building the checks into your own code.
Hardcoding the policies in your code is a very bad practice I think. In that case you mix the business logic of your resources and the permission check of the access control system. XACML is a big step in the right direction because you can create a fully automatic access control system if you store your rules in a separated place (not hardcoded in the business logic).
Btw you can store that rules in the database too. For example (fictive programming language):
hardcoded RBAC:
#xml
role 1 editor
#/articles
ArticleController
#GET /
readAll () {
if (session.notLoggedIn())
throw 403;
if (session.hasRole("editor"))
return articleModel.readAll();
else
return articleModel.readAllByUserId(session.getUserId());
}
not hardcoded ABAC:
#db
role 1 editor
policy 1 read every article
constraints
endpoint GET /articles
permissions
resource
projections full, owner
role 2 regular user
policy 2 read own articles
constraints
endpoint GET /articles
logged in
permissions
resource
projections owner
#/articles
ArticleController
#GET /
readAll () {
if (session.hasProjection(full))
return articleModel.readAll();
else if (session.hasProjection(owner))
return articleModel.readAllByUserId(session.getUserId());
}
As you see the non hardcoded code is much more clear than the hardcoded because of the code separation.
The XACML is a standard (which knows 10 times more than the example above) so you don't have to learn a new access control system by every project, and you don't have to implement XACML in every language, because others have already done it if you are lucky...