I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
Related
I'm designing a system with REST API. REST API will be implemented using Spring Boot. The system should manage employee, product, orders information. It can be used as a standalone or as a part of some existing product ecosystem. I'm looking for some resource (book, blog, online course, etc.) to help me decide how to implement authentication and authorisation.
It's quite obvious how to do it if the system is used as a standalone product. User credentials/authorisation data can be stored in the same database next to product/employee and other data.
I'm not sure how to handle everything when the application is a part of some existing ecosystem. What if:
Someone wants to reuse existing User data store for authentication or third party service like Okta or Auth0.
Use existing data to build authorisation rules. For example authorise a person to modify product data if the person belongs to some User group.
I'm thinking about Oauth2+OIDC solution. For example Okta allows add a Claim based on Expression. User groups can be provided as Claims too. It seems Okta could be a source of both Authentication and Authorisation information. I'm not sure if it's a correct way to use Oauth2 and OIDC? What are potential pitfalls storing the authorisation data this way?
I've checked Keycloak and it seems authorisation data. can be stored there. So it's not an unusual practice to manage such a data in an authorisation server.
Maybe I should use Oauth2/OIDC for authentication only? Authorisation data (assigned roles, groups, etc.) can be stored in my application database. The application should provide means to manage the information.
I'd like to get some advice or source of information for this topic.
Thank you.
I would aim to keep OAuth data fairly small - the Authorization Server (AS) typically only needs a few fields to manage login such as Name / Email and a generated user id.
When data becomes domain specific it can become a burden to manage it in the AS, whereas in your product data it is easier to spin up custom UIs etc.
Instead the AS can reach out during token issuing to an API to include important claims in access tokens - such as roles etc. Meanwhile you don't want to expose detailed access tokens to internet clients.
The Curity web site has some good resources on patterns to meet the above requirements - here are a couple of links:
IAM Primer
Claims Best Practices
Suppose you have two endpoints in a mule application and you want to restrict access of one endpoint to a particular client application and make only another endpoint available for access.How can you implement this?
You can use a custom policy to achieve the same. So far, there is no OOTB policy available for the same. The other thing you could do but is not as elegant a solution ( this is also applicable in case you are not using API manager aspect of the platform) is making use of filter in the Mule application (Mule3) and validation module in Mule4 whereby if the incoming request (for a given resource/HTTP verb combination) has a particular clientId you drop/filter that request while you let others go through..
I have a bunch of microservices running. I have an api gateway that connect consumers to all these services. Now on some services I need to give permission to certain users ( users are stored in separate Users Service ). For example if I have a blog service I need to give blog 1, blog 2 and blog 3 view permissions only to user 1 and not to user 2 ( the scenario is acl rather than RBAC or ABAC i think, correct me if i am worng ). Now how should i implement the permission system.
For example If store the permission on each entity object inside each microservice as suggested here then each of my service has to know about users also to grant them permissions. this scenario will compel me to synchronize the users data across all microservices ( on users delete update ... ).
Another Solution is to create a separate generic authorization service to manage all services permissions. but this solution will require me to save each microservice schema ( and have to synchronize that schema on change )
Or there is any other solution. please help. how to implement ACL (authorization)
One solution would be to introduce userID into the downstream path from the gateway. So the path
GET /blogs/{blogId}
is exposed on the gateway, but this becomes
GET /blogs/{userId}/{blogId}
on the blogs microservice. The gateway handles the user's bearer token and injects the user's ID into the downstrteam call. The blogs microservice would then return the blog for a "valid" path, or a 404 if the path was not valid.
This is illustrated here:
the backend service maintains which users have access to which blogs?
The blog microservice stores and manages blogs. A blog can have an access list associated with it. That list may contain only the user who is the blog owner, or more than one user. The point is that the ACL is not centralised, but distributed with each blog's data containing it.
if a user is deleted
Then you have two choices. If the user is deleted you publish a UserDeleted event, to which the blogs service is subscribed. Then you can manage all the blogs which have the user in their ACL and remove them. Or, you can do nothing. I would personally choose the latter; one of the features of having a microservice architecture is that some data will not be consistent. If you require absolute consistency then you can have a "caretaker" process which removes deleted users out of blog ACLs. Or don't use microservices.
I've implemented an application using Moqui Framework. I provided url:http://localhost:8080/fvl-plus-runtime/rest/s1/example/examples
It is getting error like:
User [null] is not authorized for View on AT_REST_PATH [/example/loginexamples/{username}]
You can add ArtifactAuthz records for all users, like the ones already in place for admin users for the REST APIs. In general it is best to secure all API access, and that is how things are setup by default. There are various examples you can follow to see them in action, see the extensive comments in the rest.xml file (the XML Screen for the /rest path).
This feature as been added in commit #44272ba. You are now able to create a new REST service and set require-authentication=anonymous-view or anonymous-all.
See How to create a publicly accessible REST API in Moqui for more details.
I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.
Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?
Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?
I hope my question is clear. Thanks for the help.
From what I understood in reading this there are two parts to your question:
What is the best authentication method for my API?
I recently developed an authentication system for an API that was modelled on OAuth but didn't have every single one of their specifications. The system was basically the same as what Amazon use for their API. [This article]1 is very helpful if you want a secure API authentication model without having to use OAuth.
The model uses these principles:
Authentication data will be passed with every request to the API server
Requests will include a Unix timestamp from when it was generated
The entire request (including the timestamp) will have an HMAC hash generated and sent alongside the rest of the data. The hash is generated using a private key that only the API server and the API client know.
The API takes the data (including the timestamp), generates an HMAC hash using the private key for that user (identified by a user ID, user name, public API key, whatever) and compares it to the hash sent with the request. If this was successful, regular authentication proceeds and the request is processed. Note: the API will check the timestamp and compare it to its own to make sure the request has occured within a valid timeframe of, for example, 30 seconds, 5 minutes, 10 minutes, etc.
Of course, you can use regular HTTP authentication over SSL/HTTPS also, but I find this way to be very good because you achieve a high level of security without needing to implement every aspect of the OAuth protocol.
How you authenticate is up to you essentially. I prefer to go with methods employed by large, trustworthy organisations (such as Amazon). I personally didn't want to go the whole hog with OAuth like Twitter, Facebook etc.
How should I allow different users to access different endpoints in my API?
You should have an internal map in your API server which contains records allowing or denying specific API accounts from accessing certain endpoints. In my API server I decided that all endpoints would be "allow" by default, and I would specify which accounts would not be able to access certain endpoints.
You could also set up different groups or types of API access accounts which could have group permissions like this.
My suggestion would be to [read this article]2 twice, or three times, then read it again. Then, implement the methods suggested within.
Personally, I think the best method for ensuring as much security as possible is to restrict absolutely everything in regards to the request to be within a set of boundaries that you define, e.g. I want this endpoint to only be accessible by GET HTTP requests (all other HTTP methods will throw an error), up to 3 times daily per account, within a 30 second timeframe of request to server, only allow a narrow range of data to be returned, etc.
Limiting the HTTP method is very important to reduce the risk of your API doing things it shouldn't, especially with a RESTful API as endpoints can be used to do multiple things depending on the request method. You can even set your permissions for each API account to restrict certain methods on each endpoint, e.g. API user xxx can GET information from an endpoint but cannot POST, PUT, PATCH etc, or API user xxx2 can POST data but cannot GET any, etc.
[EDIT] 1 and 2: www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ (not completely removing the link but keeping the url unlinked as it no longer works/redirects to random sites)