I would like to set a quota on how many times a given user can call a WCF service or a particular function in that service over a given time period (probably a rolling one hour time window). My service would require authentication, giving me enough information to actually track this type of data.
I'm looking to make this a configuration change that can be added to any existing WCF service. I'm fairly sure this functionality isn't available out of the box, but if it is please just point me in the right direction.
If it's not already available, what interfaces/base classes do I need to implement/inherit to create a class that I can add to my config to perform this type of quota tracking activity?
The information related to quota's on MSDN is all related to a single request: http://msdn.microsoft.com/en-us/library/ms731078.aspx.
To me it sounds like a special kind of authorization. The correct place to put this logic is in a service authorization manager. WCF built in quotas are per a single message and not what you are looking for. Also you have special logic like when to clear limit, how to priorize users with specific auth mechanism etc.
Related
We have an application where there are lots of permissions as claims. Loading these when the user user logs in and setting them as part of the token makes the token very large.
My thinking was to find some way of load and adding claims dynamically to the token on every call (maybe from cache to speed it up).
I know openiddict offers a bunch of server events and am wondering if one of these might be a good place to put this logic.
Is there another way this can be achieved?
Our API is designed using many permissions and I don't wish to load them each time and put code inside each api to achieve this so adding claims to the principal seems logical.
Would appreciate being pointed in the right direction.
Our API is designed using many permissions and I don't wish to load them each time and put code inside each api to achieve this so adding claims to the principal seems logical.
Then what you currently have is pretty much your best option. You could also enable reference access tokens to store the actual token payloads in the DB and make the tokens returned to the clients smaller.
If you were willing to do that at the API level, you could use the claims transformation mechanism to add claims on-the-fly: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.iclaimstransformation?view=aspnetcore-5.0
We want to make our API stateless.
Right now, the tokens for users are provided via 3rd party, upon login, and stored in the application memory.
As long as the token is in use, it is valid. Until it is idle for a configurable amount of time.
On 3rd party's side (the token provider) this token is valid for much longer (For example: A month on their side regardless of usage VS. 20 minutes of idle time on ours).
Meaning, each usage of this token updates the timestamp in the application memory.
As part of making our API stateless I've encountered a problem:
Assuming we will have more than one application and a load balancer,
how do i maintain the user management between 2 applications?
I know how to restore the users profile/details if the token isn't in the application memory (but still valid on 3rd party side), but i can't know the timestamp of it's last usage.
I think that i either have to sync the cache between my applications, or manage the users on another service.
I'm hoping that my explanation is clear enough.
My questions are:
What is the best practice for this issue?
Where can i find useful information regarding user management across multiple applications? I think that i'm struggling with key words in this case.
Thanks in advance
From the architectural point of view separate user manager is preferable. In this case you will never turn to your 3rd party token provider directly but do it via your own manager that stores tokens and the timestamps. This however will probably require a serious refactoring.
So, other solution that I can offer is probably using tool that provides sharing memory among processes and machines. For example you can use Hazelcast. It is very easy to start tool with very user-friendly API. If for example you store mapping from token to timestamp in map now the only thing you have to change is the place where you create map. Use the Hazelcast map factory instead of new HashMap<>() and your tokens will be magically distributed among your applications.
So I have a nice set of Spring Data REST repositories and they work great. Now I want to secure the data they produce. The URLs to the repositories are secure, in that, only an authenticated user has authorization to call them. However, only data in the database associated to the user should be sent to the client.
I have implemented an interceptor which gets called prior to the repository call which contains information about the logged in user, but I'm not sure how I can ensure only data produced by the REST call is data associated to the logged in user.
Obviously the client is coded to only make calls with links associated to the currently logged in user, but a user could simply change the URL to look at data they are not supposed to see.
Has anyone solved this issue?
Thanks,
Cory.
If you're using spring security, you can insert additional filters (ideally, based upon the url, or domain object.)
If you want object level security, you can still do the same thing, but you're going to have to somehow specify who/what role is allowed to access which domain object/id combinations, in either case, I don't think spring data rest handles (or should handle) any of that.
Spring Security's #PostFilter allows you to filter collection or arrays on the basis of authorization.
#PostFilter ("filterObject.owner == authentication.name")
public List<Book> getBooks();
Check these documented examples
https://github.com/spring-projects/spring-data-examples/tree/master/rest/security
Im steadily building the resources of my API, however after much research on the correct ways to build a RESTful API, I have been unable to find an example of how 'complex' requests should be received.
For example, as part of the login process (which is little more than an authentication key update), the following URI is dispatched by the client:
/api/auth/login
There are no values on the URI, the resource is /auth/ and the command being triggered is /login/. The actual login details are sent to the server Authorization header.
Now, what prompted me to ask this question is as I was writing a command to allow the client to get a reminder of how long the key is valid for, I was immediately drawn to getkeyexpiration or something similar as a command name.
Suddenly I felt that this doesn't sound like what I read about in the 6 constraints, this feels more like operation calls.
So, based on the above examples, is this still a RESTful API? I am concerned as I cannot think of a way to perform this by simply using URI resource names and appended values.
Thank you
EDIT:
From reading this: http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
I am starting to understand that by naming resources and only resources with noun words, the context of how the server will operate becomes a lot clearer.
Regarding my above example:
/api/auth/login
I have used auth as a prefix of login, because that is the context of the resource. I am designing my system to be extendible and require a way to categorize resources on the URI level. Is there a standard way of doing this?
Your RESTful resources should be nouns, because HTTP provides the verbs.
I would suggest something like this instead:
/api/key
Which you can then POST to (with HTTP Authorization headers included) create a new key, returning something like this:
/api/key/1234ABCDBLAHBLAH
This is a key specific to your session, which you can then GET to retrieve details about it such as expiration time, etc. You will have to pass that key with each subsequent request, of course.
If the key stuff sounds clunky when discussed in the context of a RESTful API, it's because it usually is. Sessions are human/browser concepts, but RESTful APIs are application/integration concepts.
Since servers don't "log on" to other servers, this begs the question: if you're already OK with requiring the caller to pass an Auth header to your login API, why not just require it be passed for each API call, and forget the notion of keys altogether?
This question crossed my mind after I read this post:
“Common REST Mistakes: Sessions are irrelevant”
If sessions are indeed discouraged in a RESTful application. How would you handle licenses in such application. I'm specifically referring to concurrent licenses model and not named licenses. i.e. the customer buys X licenses which means the application may allow up to X users to be logged in simultaneously. Which means that the application must hold a state for current logged in users.
I know I can create a resource called licenses, which will set a cookie or generate a unique ID, and then the client will have to send it with every request. But it's the same as creating a session, right?
If I'll adopt the stateless approach and ask the client to create an authentication token for every request how will the application know when to consume and release license for that client?
Is there an alternative? specifically a more RESTful alternative?
Let me try to connect the dots for you, assuming I interpreted your question correctly.
The link you posted has a valid answer, each request should use a HTTP auth. If you need the concept of licences to maintain a certain state for your user, you can most likely link that to the user. You have a (verified) username to go by. You just need to invoke that controller for each request and save its state. There you have your session.
Cookie input should never be trusted for any critical information, but can be very useful for extra verification like a security token. I think adding a random security token field to your on-site links would be the restful approach to that. It should expire with the 'session', of course.
You may want to consider pushing the license handling concerns down the infrastructure stack one level. Sort of like an Aspect Oriented Programming (AOP) approach if you will. Instead of handling it in the application tier, perhaps, you can push it in to the web server tier.
Without knowing the details of your infrastructure, it is hard to give a specific recommendation. Using the *nix platform as an example, the license handling logic can be implemented as a module for Apache HTTP server.
This approach promotes a separation of concerns across your infrastructure stack. It allows each layer to focus on what it is meant to. The application layer does not need to worry about licensing at all, allowing it to focus strictly on content, which in turn keeps the URL's clean and "RESTful".
If your licensing is based on concurrent users, implementing HTTP digest is trivial, and will let you enable only the maximum number of concurrent logins. Digest has provision for passing expiration data so your session can be timed-out.
Authentication state is hold by http authetnication and nowhere else, beause it is transparent and ubiquituous.
Maybe a more RESTful way of doing licenses would be to limit the rate at which requests are handled, rather than the number of concurrent sessions. Keep track of the number of requests in the last hour, and if it exceeds the number the customer has paid for, serve a 503 Service Unavailable response, along with some text suggesting the user try again later.