We have a SCIM api running on production and we are running into problems with a Group PUT.
I have scanned the official SCIM spec, but I am not able to find an answer for this-what should happen when a Group PUT is called with a payload that has members: [...]?
To be absolutely exact, if we receive a PUT with body like this:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"externalId": "8a06f2c2-aaaa-401b-b2b6-f54e5dac6f34",
"id": "7447",
"displayName": "Whatever",
"members": [
{
"value": "322257"
}
],
"meta": {
"resourceType": "Group"
}
Since this is a PUT we remove all members from that group and then add user 322257 to the group in a single DB transaction. Is this correct? PUT should replace all the SCIM attributes, so I would hope it is, but from what Azure cloud SCIM calls to our side it might seem like maybe we should not remove members here? Maybe we should keep the current members and just add the user 322257?
Your interpretation is correct - the PUT request you provided should remove all group members and add only 322257 as a member. While the SCIM RFC mandates that you need to support PUT, in practice only POST + PATCH should be used for create/update, respectively.
You mentioned:
but from what Azure cloud SCIM calls to our side it might seem like maybe we should not remove members here?
The only way that Azure AD's SCIM service will issue PUT calls is if an application in the gallery with provisioning enabled has been configured to use PUT rather than PATCH. At this point in time any new provisioning integrations built for Azure AD require PATCH support for groups, and will never see PUT used. If you have an application that is still configured to use PUT on groups, that application should be updated from Microsoft's side to update that behavior, assuming the SCIM implementation on the other side supports PATCH on groups.
Related
I'm getting a "Request header is too long" error when i was trying to access my API and send token in header. How we can manage a permissions in access-token because i have a lot of permissions in access-token it's approximately 15kb in size.
I know it's not recommended to store permissions in access-token then what's the best approach to authenticate and authorize the users on API side?
We are getting all the permissions in access token but now permissions are getting large as we have lot of modules. What is the other way to access user permissions in asp.net core API instead of keeping it in access token?
{
"roles": [
"Admin"
],
"iss": "Issuer",
"sub": "sub",
"aud": [
"https://example.com/api",
"https://example.com/userinfo"
],
"iat": 1666198659,
"exp": 1666205859,
"azp": "azp",
"scope": "openid profile email offline_access",
"org_id": "company1",
"permissions": [
"permission.1",
"permission.2",
........
"permission.150",
]
}
This could be a solution: https://fga.dev/. There's also the open source version: https://openfga.dev/
Basically, since every user has a lot of permissions, you don't store them in the token anymore; you can call this service which stores them for you.
Disclaimer: I am part of the team building this solution :)
You have two options.
You can try to shorten the permissions down using something like the approach here. There are lots of other similar questions with similar approaches. However, know that you limit your number of permissions based on what you inherit from so this may or may not work. You can stick a string into the JWT with each char working as a flag for a permission. This comes with more downsides, namely keeping the data up-to-date.
You setup a remote system for authorization. Something like Policy Server from Duende. This means no authorization data in the JWT. For instance you can make a simple http call to your identity server from your api/client and have the identity server evaluate if the user can do what they want to.
The latter seems right for your scenario because of your large amounts of permissions. It comes with overhead but there isn't really an alternative. https://github.com/Perustaja/PermissionServerDemo is an example that uses the built in ASP.NET Core authorization evaluation along with gRPC for the network calls. You can make something leaner and simpler that basically does the same thing if you don't want a lot of infrastructure.
How it generate? How I can validate it?
https://developer.bigcommerce.com/api/webhooks-getting-started
{
"store_id": 11111,
"producer": "stores/abcde",
"scope": "store/order/statusUpdated",
"data": {
"type": "order",
"id": 173331
},
"hash": "3f9ea420af83450d7ef9f78b08c8af25b2213637"
}
This was answered by #KarenWhite, their developer evangelist in this thread.
https://support.bigcommerce.com/s/question/0D51B00004G6kJf/incoming-webhook-posts-hash-field-in-payload
It is hashed with SHA-1, but it is not signed with the client secret:
$payload['hash'] = sha1(json_encode($payload));
Additionally, the stance on webhook security is documented in the 2018 townhall
https://support.bigcommerce.com/s/article/BigCommerce-Town-Hall-February-2018
Q. How can I make sure that a webhook callback is initiated by BigCommerce only, and that the data is not altered between BigCommerce and my server endpoint? Can the hash returned in the webhook payload be used to verify the request?
A. Our webhooks today contain very little information -- they only contain an I.D. to go look up additional information. You would need to be authorized to verify that I.D. against the store’s API to determine the actual information being requested. We also secure our webhooks with TLS encryption, and enable developers to add their own headers to events for additional security.
I believe the hash is simply a unique identifier for an event.
One good reason to have this is when you ingest events, if you ever get duplicates from BigCommerce (which I've seen happen recently) you can tell that it's a duplicate based on the hash field.
I'd recommend using a custom header to validate the payload was from BigCommerce as noted in the getting started guide:
A headers object containing one or more name-value pairs, both string values (optional). If you choose to include a headers object, Bigcommerce will include the name-value pair(s) in the HTTP header of its POST requests to your callback URI at runtime. While this feature could be used for any purpose, one is to use it to set a secret authorization key and check it at runtime. This provides an additional level of assurance that the POST request came from Bigcommerce instead of some other party, such as a malicious actor.
I am working on an API in a system that has very complex access control rules. Often times there are complex SQL queries required to determine if a user has read or write access to a particular resource. This causes a lot of complexity and redundancy in our client applications as they have to know all these rules in order to determine whether to present the user with CRUD options for each object.
My goal is to reduce much of the complexity on the client side and house all the complex logic in the API. This way new client applications written against our API can avoid re-implementing the complex access rule logic on their side when ensuring that the UI only presents valid options to the user.
I am not sure what the best way is to handle this. I'm considering two different options but I don't know if there is a better or more standard way to expose generic access information to callers of an API.
Option 1
When a caller makes a GET request on a resource entity or collection of them, every returned entity will return an _allowed_actions field attached, which is an array of actions the caller is allowed to perform on that entity. For example, requesting a Listing object may result in the following response.
GET /listing/5
{
"id": 5,
"address": "123 Foo Street",
"city": "New York",
"state": "New York",
"price": 457000,
"status": "pending",
"_allowed_actions": ["READ", "UPDATE", "DELETE"]
}
Still unsure how to relate to clients whether they have the authority to create instances of a resource entity using this method, but perhaps the client will simply need to maintain enough understanding of the permission structure to determine this on its own. The access rules around creating instances are typically less complex than the READ/UPDATE/DELETE access rules so that doesn't seem too bad.
Option 2
Create a meta-API, which clients can make requests to in order to determine what actions they can perform on each resource. For example, checking what the client can do with a listing:
GET /access-query/listing/5
{
"allowed_actions": ["READ", "UPDATE","DELETE"]
}
And checking what options are allowed for listings in general, including CREATE:
GET /access-query/listing
{
"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}
The benefit of this approach is that it allows callers to have a full understanding of what they can do on every resource in a generic way. This way clients wouldn't have to understand that the "create_listing" permission AND a non-probationary user status are required required in order to create listings. They can simply query for this information ahead of time.
The downside to this approach is that it increases the amount of requests. Rather than require clients to have an understanding of the permissions logic, they now have to query once to determine what they can do and a second time to do it.
I don't particularly care for either of these methods but they're all I can come up with at the moment. Is there a better way to go about this?
What you are looking for is fine-grained, externalized authorization:
fine-grained: you want to create authorization policies that take into account multiple parameters or attributes and possibly relationships between the client (the requestor) and the targeted entity e.g. a listing in your case.
externalized: you want to decouple the business logic from the authorization logic. In your question you complain about how complex the code and the SQL statements are becoming. This is a direct consequence of not clearly separating business logic from authorization logic.
There is a model called attribute-based access control (ABAC) that defines an approach to fine-grained externalized authorization. NIST, the National Institute of Standards and Technology, has produced a report on ABAC which you can read online.
OASIS, the organization for the advancement of structured information standards, has defined a standard called XACML (eXtensible Access Control Markup Language) to implement ABAC.
XACML brings you:
an architecture as illustrated below
The policy enforcement point (PEP) intercepts your API calls. It protects your API, inspects the messages and sends an authorization request to the policy decision point (PDP).
The policy decision point (PDP) evaluates incoming authorization requests from the PEP against a set of authorization policies written in XACML. The PDP eventually reaches a Permit or Deny decision. To reach decisions it may need to look up additional attribute values from databases, web services, LDAP, or files. These are called policy information points in the architecture.
a policy language: the XACML policy language is attribute-based which means it uses attributes to define what can be allowed and what is not. For instance, you could define rules such as:
a real estate agent can see all the listings if and only if the listing location == the agent location
a real estate agent can edit a listing if and only if he/she owns the listing
a real estate agent can close a listing if and only if the listing's item is sold and if and only if the agent is the person that sold the item.
a request/response scheme: XACML also defines a way to query the PDP and to get responses back. A PDP can be queried either via single questions or via multiple questions in a single request e.g.:
Can Alice view listing 123? Yes, permit.
Can Alice view, edit, or delete listing 123? Permit; Deny; Deny.
With a XACML-based approach, you get to maintain your business logic and your API separate from the authorization logic. This has several benefits:
you can always reimplement the API and keep the same authorization model
you can easily expand your API without having to rewrite the authorization
you can change your authorization logic independently of your code
you can audit your authorization logic more easily
your authorization logic is technology-neutral. It works for REST APIs, web services, databases, and more
I recommend you check out the following resources:
the OASIS XACML website
the ALFA plugin for Eclipse - a free tool to write XACML policies.
The XACML developer community
There are both vendor and open-source implementations of XACML:
Axiomatics is a vendor solution that provides both .NET and Java XACML implementations
SunXACML is a long-standing open source Java XACML implementation
HTH,
David.
Not trying to resurrect an old question, but I came here searching for almost exactly the same thing and wanted to add a solution that I think is more RESTful.
I haven't actually implemented this but think it may help others who come here...
Your second option is very nearly what I think should be done, but instead of a get use the OPTIONS verb to your resource which will then return an "allow" header with a list of available verbs for that resource.
OPTIONS /listing/5
Assuming your resources are fine-grained enough for this to make sense, then you would know if you can make a POST/DELETE
as part of a server REST API design I'm considering I'd like to be able to return data that is conditional on the level of authorization of the client. What would be the recommended way of doing accomplishing that and still calling it one API? More specifically, consider the following example for a book access API:
HTTP GET /library/books/{book-name}
Any authenticated client should be able to get (JSON) data for the book, like:
{
"book":
{"book-name":"abc", "author":"someone"}
}
But a specific sub-set of authenticated clients should also be able to get:
{
"book":
{"book-name":"abc", "author":"someone"},
"private-info" :
{"book-status":"on-loan", "price":"$20"}
}
For a given book, any suitably authorized client can also access the "private info" via a direct HTTP GET /library/books/{book-name}/private-info.
Now, assuming a suitable client authentication scheme is in place, I cannot help but think that the HTTP GET /library/books/{book-name} above is actually looking like two API's, distinguished by authorization state on the server regarding authentication. This seems not very RESTful.
Perhaps it would be better to keep the base GET book API the same for all without ever having any "private-info", while offerring authorized clients only access to the private-info URI and returning 403 to all others?
How does this type of conditional data access typically get handled with REST APIs?
There is nothing inherently wrong with your approach - it makes good sense to hide information as you suggest based on the user's authorization. REST says nothing about this - the representation of a resource may depend on user authorization, moon phase or what ever else you can think of.
You can although improve caching if you extract the private information to a separate resource. In this case you would have some rather static content for /library/books/{book-name} which can be cached on the client side. Then you would have /library/books/{book-name}/private-info which would be more volatile and user-dependent - and thus not easily cachable.
Building on this you can include a link to the private information in the original resource:
{
Title: "A book",
Author: "...",
PrivateInfoLink: "http://your-api.com/library/books/{book-name}/private-info"
}
The benefit of this is two-fold:
1) The server can leave out the link if the client does not have access to the private information and thus saving the client from a unnecessary round trip to (not) get the private info.
2) The server is free to change the private-info URL if it needs so later on (it could for instance be different URLs based on the user authorization).
If you want to read more about the benefits of hypermedia then try this: http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html
I recently answered a similar question. You can find my answer here.
The bottom line is: You should try to separate business logic from authorization logic always. This means you want to externalize your authorization. There are several ways of doing that.
In your particular case, imagine the list of sensitive fields that only a subset of clients can view changes over time, that would potentially require a rewrite of your API. If you decouple authorization logic from your business logic (API) then you can easily update authorization logic without having to rewrite any code. This is called externalized authorization management (see this great Gartner paper on the topic).
As part of my day-to-day job, I help clients secure APIs and web services using XACML. The best practice is always to keep concerns separate.
I'm currently designing a REST Http api. (With HATEOAS stuff, to make clients "simpler", and avoid clients to do complicated things, instead of letting the api tell them what to do ...)
Because of the social characteristic of the app, in order to interact with the application, users need to be authenticated, and each user will have a slighty different "view" of the data.
We'll take twitter as an example, it will be easier for everyone.
To authenticate users, we'll use OAuth, easy.
So, in the client (ios app...), a random user would maybe seeing a list of users should see:
Adrien: Following
John: Not Following
Rambo: Not Following
And another user would maybe see:
Adrien: Following
John: Not Following
Rambo: Following
To achieve this, the first solution would be for the client (in oauth term, the iphone/web/etc app), to get a list of all the users the authenticated user follow, and each time the client displays a list, compare each user with the list of followed users to know if it should display "Not Following" or "Following".
The requests/responses would be:
GET /users
Authorization: OAuth token...
[
{"id": 1, "name": "Adrien"},
{"id": 2, "name": "John"},
{"id": 3, "name": "Rambo"}
]
and
GET /users/{myid}/following
Authorization: OAuth token...
[1, 3, 25, 1210, 9]
This seems to be quite, stateless. Good.
Now what if i want to make client developers life easier, and embed directly in the user list response, the relationship of each user, relative to the authenticated user:
GET /users
Authorization: OAuth token...
[
{"id": 1, "name": "Adrien", "relationship": "Following"},
{"id": 2, "name": "John", "relationship": "Not Following"},
{"id": 3, "name": "Rambo", "relationship": "Following"}
]
So, questions:
It seems to break the "stateless" thing, does it really break the REST stateless constraint ?
Next, do you think it is a good or bad practice for an api to do this ?
You should definitely embed the relationship in the user list response. It would be bad practice to force the clients calculate it.
This does not break the stateless constraint of REST as it's the interactions that are stateless, not the systems. The server will almost always have to store and maintain state. For instance the server will need to maintain state of who is following who.
Finally, I think you are not fully getting the "State" part of Hypermedia As The Engine Of Application State. Basically, the resources are state machines. When you GET a resource, the valid state transitions are presented has hypermedia controls (links and forms) in the response. It's by following these links and submitting the forms that the client can change the state of these resources.
Including the description of the relationship type in the response body is not breaking the stateless constraint. The stateless constraint means that the web server can respond to the request without being dependent on any previous request (as has been mentioned by Tom, Jacob and kgb).
I'm not qualified to say whether what you're doing is a "best practice" or not, but in general Roy gave the following reasons for and against making your API stateless (see section 5.1.3 of his dissertation). Like many things in life there is a trade-off:
Problems with a Stateless System
Requests may need to be larger. Since data is not stored on the server between requests, each request may need include the same things over and over again.
In a stateless system, the server is dependent on the client maintaining the state correctly.
Benefits of a Stateless System
You know what a request is trying to achieve based solely on its content.
Reliability, since it "eases the task of recovering from partial failures". See reference 133 cited in Roys dissertation for more info.
Improved scalability. Managing state between requests, particularly in a distributed environment can be quite complex. The first thing that comes to mind here is ASP.NET InProc session state, fine for a single server, single process instance, but it doesn't scale very well.
RESTful Resources
Also, according to Roy's definition of a resource I'd take issue with how I think you're defining your resources, with each user getting a slighty different "view" of the data. Roy defines a resource as a membership function that varies over time (see section 5.2.1.1 in the dissertation). The user list resource you've defined above varies by both time and by the Authorization header. Two different clients requesting /users at the same time would most likely end up with completely different results. This will make caching the results more difficult.
EDIT: Using the HTTP vary header would allow it to be cached.
If you think adding "relationship" property to users breaking stateless constraint, then adding it when "/following" is in the request, would be breaking it too.
I would say "stateless" means no response depends from the other requests/responses.
HTTP is a stateless protocol, but it can store quite a lot of data about the user in the request/response headers(and i am not talking about sessions/cookies)
From Roy Fieldings Architectural Styles and
the Design of Network-based Software Architectures:
3.4.3 Client-Stateless-Server (CSS)
The client-stateless-server style derives from client-server with the additional
constraint that no session state is allowed on the server component.
Each request from client to server must contain all of the information necessary
to understand the request, and cannot take advantage of any stored context on
the server. Session state is kept entirely on the client.
Link: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
So you embedding entity data directly in the response does not make your solution non-stateless.
On good practice:
It's a lot better to actually serve the user data than a list of numbers for the client to figure out what to do with.
However, depending on the amount of data for each user, you could consider giving a list of links to the user resource and state the "follow" relation as well. Then the client can fetch the details on the needed users. Which solution you choose should depend on what you believe the client will be needing, you might end up using several approaches.
I don't see the correlation between embedding the "relationship" information into the /users resource and the stateless constraint. So I see no issue.
However, I would argue you are breaking the "identification of resources" constraint.
/Users for you and /Users for me is going to show a completely different set of relationships. I would argue those are two different resources and therefore should have distinct URIs.
There are some scenarios where you can change a representation based on who the user is (for security reasons for example) but this case is just too much change for my liking.