Rest API Design for Order Management System - java

I am working on a project which is using micro-services architecture.
There is two services:
UserAPI : all thing related to user come here.
OMS : All things related to Order Come here.
I need to provide orders based on following filter :
By User Id
By Date
By Status
By User Phone Number
mix of above
So i create an API
path/orders?date=12/11/2016&status=delivered&phone=1111111111
Now i need to provide Orders for User by user ID. So which is good rest design:
Add user ID in query param in existing API like path/orders?user_id=1
Create a Separate API path user/{user_id}/orders

Both of your options are OK. But there are different semantics.
path/orders?user_id=1
This is looking up by orders. Orders maybe looked up for example to do some statistical analysis. The orders can be filtered by different parameters, the user id being one of them. For this (when the orders is the main interest) the above URI strategy is fine.
Now on the other hand you may want to look up a user and see their orders. Maybe to do some analysis on their ordering habits. Here you want user information along with their orders. This is where your second URI scheme would be better
user/{user_id}/orders
These are the orders that belong to the user. So it is a relationship. This is where this URI scheme works better.
So really there's nothing wrong with having both options. You just need to follow the semantics of when each should be used.

Related

Validating data across multiple microservices

I'm trying to understand how to develop and manage microservice using Spring-Boot.
In my situation I'm managing a Restaurant and its Orders, having a List of Products and a order-level DiscountCode. The Products can have their own priced discounted (the owner of the restaurant can set as true the discountedPrice of the product and even let apply the discountcode for the entire order).
The part on what i am struggling on is the following:
How should I manage the validation for the Order? When an order has been created it should check using the other micro-services to make the order completed and valid to be processed.
The steps are:
Order created
Verify the products and its price and if they are discounted as passed by the FE
Verify the existence of the discountCode and apply it to the order
Should I create a different component that receives the order created and validate them asynchronously (using RabbitMQ) and getting the information from the other microservices?
Thanks in advice
That's a difficult question, because we did not knwo the domain and the existing services.
Each service should be responible for its own validation. To check if the discount is valid I would prefer that the Discount-Service should do the validation.
If it is same as the order service, the order service should get back the object and validate it after getting the prices.
But it's up to you and your domain.

Role-based access control in UML

I'm trying to figure out what I need to specify in UML for a role-based access control system.
Basically I have a Database and only specific people are supposed to access specific functions or informations from that database. My academic helper told me to use a role-based access control system and scribbled some stuff onto a paper.
On the left you can see the 3 roles, and connected to it the database, both in the model part of the Model-View-Control.
My question basically: Which functions/variables do I need in the class Role and the role classes so the access control system works and why?
Generally this is supposed to be written in Java.
EDIT: Each Role has its own login credentials, so they will be identified upon login. With this login they are supposed to get one of those roles, but I don’t know how to give them that role.
I was looking for some diagram I found via google a long time ago, long before this question.
RBAC is a standardized model, it doesn't really contain multiple representations. You can extend it with additional security models, and it's multilevel, so higher levels are optional.
Flat RBAC, the first level, requires the following
users acquire permissions through roles
many to many user role assignment
many to many permission role assignment
user-role assignment review (user - role mapping can be changed, not hardcoded)
users can use permissions of multiple roles simultaneously
I have never seen a full implementation of RBAC in the wild. In a previous job we ultimately had to add point 2 to the application to enable administrators to go into a "support" mode, to view an accounts profile as they would.
This diagram gives a largely complete level 4 representation.
Here is the source of this diagram, it has a lot more information than what I'm saying.
I think the biggest variance you'll have (besides naming) is what object has "check access" and the general naming of these objects and methods.
For further reading on the subject, I would suggest these
Role-Based Access Control, Second Edition
ANSI blog
ANSI specification
NIST 4 levels of RBAC implementation
NIST adding attributes to role-based access control
Wikipedia RBAC, also contains UML
There are other documents including some criticisms, I usually find that simply using RBAC is not sufficient, as there are often more complex requirements than just "manager can do X", for example.
Well, still there are many, many ways to model this. And basically it's not an UML but a design issue. Anyway, here's a possibility:
A user has a single Role which is permanently assigned during a login. Of course a user with admin privilege could alter this role to something else. The Role holds a list of assigned Applications where the association class RoleApplication can hold attributes about what the role can do with the application.
Now how you control that an admin can change rights and all these pretty things that come along with a security system are definitely too broad to go here.

Filtering of data based on a DSL

Our's is a product specific to a domain.Here are some of the typical security use cases,
A normal User can edit only his profile data or anybody data based on permission
A user can see only data that belongs to his department while another user can data from all departments
These requirements changes from customer to customer so we can not just hard code the filtering logic in our application code or maintain multiple versions of the application.
We use Hibernate criteria based filtering and like to add additional Restrictions based on some expressions associated with a Permission. An expression for use case 1, mentioned above, may look like this, 'userId=user.userId' where 'user' is a keyword and represents current authenticated user and 'userId' is a property of the object for which criteria is created.
We want to define a dsl using which we can derive criteria restriction as well as 'where' clause for sql.
Are there any existing frameworks which will enable us to do it, without going for dsl? Based on the use cases mentioned above, do you think it can be achieved in different way?
Additional Info: We define only domain objects with some meta information to generate UI. Persistence, security etc are taken care by our core framework.
Have you tested Hibernate filters?
They are great mechanism for record level filtering, you can define multiple filters (for example two filters for your case) on each entity and enable or disable them according to current user.
Shall mention that filters can accept parameters (for example your current user id).
We have used this great feature of Hibernate 3 on a large project, which had a hierarchical organization unit and that worked fine.
By the way if you use Oracle as your database, consider Oracle's virtual private database feature.
We decided to go with our own dsl using antlr

How to implement sharing ability in a Spring web app?

Kind of a higher level question here.I've got a web application that is fairly simple. There are three seperate "objects" in the application. A Filter, an Authorization, and a Job. Each Job has to have a Filter and an Authorization to run.
Now a user of this application can create any of these objects and they are all linked to that specific user. Now however, the requirements state that they'd like to implement sharing. So a user can share their created items with other users. Honestly I'm just not sure of the best method to implement such a feature and am hoping someone can provide some ideas.
In the DB, each record has a user column that identifies the user who created it. I initially thought of adding a shareUser column, but that wouldn't really work since each record could be shared with multiple users. I'm just not sure the best way to tie these all together. Do I need an entirely new table in the DB that link's users to shared records?
Any thoughts on this would be appreciated. Thank you.
Yes, you do need a new table for each type of record you need to be "owned". You should use cross reference tables for this case.
something like:
userFilter
- userId
- filterId
If a user can only share a record they exist, you should have a createdByUserId column on the particular table.

How to manage a large number of permissions?

I am working on a large Java EE web-app with CRM functionalit and we are looking for a security approach/library/solution/anything. Basic role-based security won't work since access control must be based on both role and hierarchy, but must be optionally customisable per document. Because there will be confidential and proprietary information stored, it is a requirement that the security works properly.
Example: To use department store, shelf stalkers stockers can create reports that other stockers can read only if they are in the same department. Now their department manager can read/write/update/delete all reports written by stockers and write reports that all others department managers can read but not see reports of store managers, etc, whom the district managers can r/w/u/d etc. Now, the complications: people at higher levels can make things visible to people at lower levels, either to individuals (department writes document to several specific stockers) users or everyone below them (store manager writes a memo to the entire store) or any permutation you can imagine. Also, individuals can create reports that their peers cannot see or they can choose grant access to store stockers in other districts etc.
We are considering an ACL with one permission per entity, but are worried about the large number of records that would create. Even if only a report was readable to everyone else in a department of 30 and every person above them [in the chain of command], creating a single report would require ~40 records! With 1 report per week per user that is 2000 permissions per user per year. 1,500 users means over 3,000,000 permissions per year.
It seems like a rule-engine based approach would be nice, but I have not seen any blogs or articles mentioning that approach so we're hesitant to that approach.
We are also considering some ACL/rule home-brew hybrid where you could grant permission to a department id with a discriminator of "manager" or "stockers" etc to subselect, but are worried that checking for all possible permissions (you could be granted permission specifically by another user, you have permission as a memeber of your department, you could have permission as a member of a store, or of district) sounds like an error-prone tedious nightmare.
What is the best approach for our application?
You could look at using Spring Security and ACL's - the nice thing about Springs ACL implementation is it is implemented with AoP it should be easier to integrate.
It sounds like your security requirements are quite complicated - off the top of my head I dont know how you'd implement this.. but you can reduce the number of records required by creating ACL's against your object hierarchy and having objects 'inherit' permissions from parent objects. You grant a user read permissions to the parent Department of a Report - so they would inherit read access to the child reports of that department. Alternatively a Manager might have read and update permissions on the Department. The key to all this is how your java object model has been structured.
I have had a similar situation in a system where there were thousands of articles in an object hierarchy of Business Unit -- Publication -- Issue -- Article. You can have hierarchys of ACL's - so in my system - users that had C/R/W permissions to a particular business unit, inherited permissions on all child objects in the hierarchy.
In my opinion Customization + Complexity = JBoss Drools, I don't have much experience using this technology but I believe it would be worth a look in your case, check out the latest drools samples at: http://blog.athico.com/2011/04/try-drools-example-in-less-than-minute.html

Categories