We have chosen a REST based architecture for a new web based application. The entire platform is exposed in the form of a RESTful service so that any UI (WEB/Mobile) can be built on top of these. So, the application is in 3 layers, the DB, the Application layer - this just exposes RESTful services, and UI - currently a HTML5/CSS/Javascript based UI consuming web services.
This application also has role based access and hence the UI has to be designed based on the role. Is it a good idea for a web service to return the set of privileges in a service response and then use it in Javascript to build the UI?
UI variations for roles can be as follows:
Main menu might change based on the role
Tabs have to controlled based on roles
Most of the pages in the application are widget based, and display of widgets is again tagged to roles
Once again, I would like to know if this is a right idea to go ahead with. Please suggest.
To follow the HATEOAS (Hypermedia As The Engine Of Application State) constraint, you should have the REST service itself be providing what state transitions (i.e. links) are valid for the "application state", which includes any particular logic about what navigation, tabs, etc are available based on the role(s) of the user.
As such, your resources should be designed in such a way that they can return results that are specific to your logged in user.
E.g. (using HAL as the hypermedia type)
GET /users/123/navigation
{
"_links": {
"http://api.service.com/rels/home": { "href"="/" "title"="Home" },
"http://api.service.com/rels/admin": { "href"="/admin" "title"="Admin" }
}
}
Doing so keeps the business logic of "what roles can do what" in the service, which is really where that logic belongs.
for that you need to store all the menu option , widget and pages name in databse and also load menu at runtime.(i.e your first request is send role and getMnu from server)
you can easily create role based Rest ARchitecture and also provide security to Restful Services.
Related
Is it possible in hapi-swagger to hide some APIs from documentation (swagger ui) based on user role.
I mean suppose I have /employee and /admin two APIs so whenever admin login to swagger ui or swagger documentation so both /employee and /admin API should display on page and if employee login to swagger ui then it should display only /employee API.
You can hide routes by omitting the ['tag'] value in the configuration, but you cannot have this on a user based role without considerable reworking. The documentation is generated at server start not on the fly, which is why you need to reload the server to reflect changes.
I had a similar use case, and in the end I decided it made more sense to have a different endpoint for the two difference services (in your case employee and admin). So perhaps something like api.domain.com/internal and api.domain.com/external and if so desired its easy to wrap authentication around either of these. It also leads to advantages should you ever want to grant access to developers to work on one API group rather than open access to both.
I want to build a web api to deploy to Azure so that I can call it from a few separate web apps to collect user input.
The users wont be logged in, but I want to ensure that only the web applications can call the api. Thus I need some kind of authentication, and I am trying to understand my options.
In Visual Studio 15.5.4 I selected New Project-> Web-> Asp.Net Core Web Application->Web API
I am wondering how ensure that only my web applications can call the web api.
I tried clicking Individual User Accounts and was surprised to find a combo box with only one option/
Have I missed a setting somewhere for there to be a combo with only one option?
If I choose Work or School Accounts instead then there is another single option combo
The combo population for the Domain combo depends on my being logged in to Microsoft, and consequently the Active Directory domains that Azure can find associated with me.
Then using the Web Application template and work or school accounts then there is a choice of Cloud-Single Organization and Cloud-Multiple Organizations.
If I am using the Web Api template then only Cloud-Single Organization is available.
I am developing a web application consisting of different domains. I have tried to implement hierarchical RBAC for authorization. Each domain has some predefined operations in their bo implementations. The following is my bo package hierarchy.
com.mycompany.bo
...domain1
...domain2
.
...domainN
...rbac
I predefine the following role hierachy at first deployment, i don't want to maintain the rbac operations after the first deployment, i mean the domain rbac operations should be self maintainable by the domain admins.
Root
Domain1Admin Domain2Admin .. DomainNAdmin
The root role can authorize on all operations under bo implementations and also each domain admin can authorize on its all own operations and some rbac operations like create user, edit user, create role etc also.
Finally, I have developed the ui part of the project abiding by the facelet facilities, like include tag so that i can distinguish the ui fragments of a page. As a result, I can render a ui fragment with respect to whether the the user authorized to view the fragment or not. Any suggestion for the authorization design of the system will greatly be helpful.
Now, I came to authentication part of the project. In this system a user does not only authenticate over internally but also should authenticate over an external system via a web service or ldap, since the user may have been already created in there.
Spring framework provides some facilities authentication via ldap(statically configurable in xml). In my case, I want to add remove edit new LDAP definitions in runtime and can change a user authentication method(may be selecting the new LDAP from a combobox). How can I dynamically add new LDAP definitions in Spring, shall I continue with spring security or implement this feature own my own?
I learned that the Silverlight Business Application template allows you to create users.
But you can also create users with the Web Site Administration Tool.
What I see is that the Administration tool allows you to create roles, and allows assigning users to those roles, whereas the pre built interface that the template offers only allows to create users which assigns them to the "Registered Users" role automatically.
I guess that if I want to offer the ability of creating roles and managing the relationship "roles-users" from the application, I should program the interface in the application. is that so?
I see that the pre-built interface the business template offers is very limited.
The built-in interface of the SL business application aims to allow a new user to create an acount and log on/off. It doesn't concern itself with actual user rights. You have to implement this separately.
I usually implement this by adding a "Settings" view in the SL app where I put a datagrid and populate (from the aspnetdb.mdf) the registered users as rows and the role names as columns.
Then for each row I put a checkbox to allow a "PowerUser" to assign each new user to roles.
To do this you have to first create (through SL or Web Site Administration Tool) at least one user ("PowerUser") and 2 roles: "NormalUserRole", "PowerUserRole".
Then you assign PowerUser to the PowerUserRole and grant him access to the Settings Page.
So:
Anone (no assigned role)-> can create a new user account and log on/off. No other rights
UserRole -> can work on site
PowerUserRole -> can assign roles to users
How do large companies implement their security requirements which are centralized and used to drive things people can do (allowed to call a certain web-service, submit an order, etc.) as well as to drive UI (disable buttons, menu options, individual form fields)?
I am considering RBAC architecture: Users -> Roles, Roles -> Privileges.
Complex applications with permissions based on many individual field-account-user-role-amountThreshhold would have many, many "Roles" and managing this gets complicated as number of roles grows.
Managing all these possible options seems daunting, and my prior experience is to hard-code such logic in the application.
Ex: If (User.Roles("IsAccounting"))
{
btnEditOrder.enabled = false;
}
I am tasked with designing / implementing a security service/architecture which will be used as common authentication/authorization point for any/all applications (all .NET, but some GUI and some process-oriented).
This is not possible out of the box because of the business organization around client accounts and permission tiers based on financial amounts.
Ex: John is a User and he can View and Submit requests for account "Microsoft" and "Google".
Mike can View "Microsoft" and "Google" requests but can only Submit "Google" requests.
Number of accounts / users is large and variable.
If I follow RBAC, there will be hundreds of "Roles" to accommodate all required Rights (Privileges). This doesn't help because the end goal is to give easy to manage GUI tool so that managers can assign their direct reports to appropriate Roles.
I was thinking to implement this security piece with the following API (rough draft in pseudo-code):
UserContext securityContext = Security.GetContext(userID, userPwd);
And usage in application would be like this:
if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}
This way there would be thousands of these 'Can(params)' methods to check permissions which doesn't make it easy to either manage or use this pattern.
Any links / ideas / pointers are appreciated.
It's a .NET shop, but nothing I've seen from .NET (Membership / AzMan) will give us the granularity and delegation requirements required. ActiveDirectory / Oracle LDAP integration would be nice, but not necessary.
Old (current) system uses LDAP to authenticate users, but all authorization is done in-house and stored in classic "Users, Roles, Rights" tables.
We were having almost same requirement, where we had multiple apps inside big organization, and we had to
Secure multiple applications for authentication and authorizations
and manage all these applications from same central location, no
matter these applications are .net or non .net, GUI based or process
oriented,
running applications might be internet based or intranet based
Applications should support AD users or federated users for
authentication and authroziation
Apply lots of 'role based' or 'permission based' security or
customizations.
ex. Enable/Disable features -like Enable buttons, Disable buttons, Hide some menus, Change background color of controls, or change any .net supported properties of .net components etc.
Secure webservice or wcf service for authentication and authorization
apply role based security for multi-tenant applications via groups
and users management
Manage organization's users for multiple applications from
central location
Tracing user's actions or auditing.