I'm looking for information on how to implement secure pages using ExtJS 4. By secure pages I mean the user will log into our website using Siteminder (SSO) and so we will have the user's identity. Then we would determine what roles the user would have by making a database/LDAP call and only render those views/components that the user has access to.
Several questions come to mind:
1.) Of course I would expect we would do the authorization check prior to rendering the pages on the server-side, so how do you do this prior to firing Ext.onReady()? I need to have the ExtJS wait for the response from the server?
2.) What is the best way to organize a page's components where the case may be someone could see a particular component and another person cannot?
3.) How do I deliver the resulting page (i.e., the pieces the user has access to) to the client?
TIA!
If you're working from a Java background and are comfortable using Spring, I wrote up an approach using Spring Security here. This will allow you to plug-in any authentication mechanism you want. The main difference is that instead of using an index.html to bootstrap the application, I have a JSP so that the Spring Servlet Filter will fire for authentication. The Ext JS app blocks until the user is authenticated and the user's roles/permissions are provided.
Use a server side technology to pre-process authorization by putting your JS App launch script into a JSP/GSP. What this does is forces server side components to kick off first and then render the HTML/JS/CSS to the client. For full RIA app use index.gsp(or jsp) and the your URL stays "domain/contextroot" .
You can interrogate access privs to content via ajax request to server or alternatively you could set JS variables via again JSP technology that is processed first before the rest of the client response is returned.
< g:javascript>
//global env var definition
var env = "${System.getProperty(Environment.KEY)}";
< /g:javascript>
Both of these are not 100% safe as client side code can be altered. The real security enforcement must be handled on server side when data is submitted for processing.
'3. Easy way would be to hide/show views etc based on 2. above. There are also some experimentation out there with modularizing the client side MVC application by lazy(manually) initializing controllers that may or may not be needed.
Hope this helps.
DB :)
I am currently experimenting with the following solution. Although it will only work for apps with a rather simple set of users, it could be of some help to you.
To begin with, user authentication is done without extjs, using a simple HTML/CSS page. Once the user logs in, its details (user id, role) are saved into the PHP session. And then the page redirects to one of two extjs apps.
One app for normal users (I'll call them clients), these are people who's client side JS does not include any admin functionality. The other app is for admins.
Both apps have their classes inherit from base classes. So we have, for example, base.mainMenu from which both admin.mainMenu and clients.mainMenu inherit. The only difference in the app.js script is the controllers loaded, and per extJS 4 dynamic loading module, only the related views are loaded (ie, seen on the client side). In my case, all pages load dynamically anyway, so my users can only dynamically load pages in their mainmenu.
The admin app blocks certain features using a global JS variable that includes the user's role. So for example, the hiding of an 'edit' button from moderators (an admin group with less rights) is done once the view is loaded (in practice this is actually done by not loading a plugin that allows editing on the view).
To wrap it all up, any call to the server checks whether the session user has rights for the requested operation, so regardless of client side scripts, server operation can only be performed by people with the appropriate rights.
To summarise, you have 3 different strategies that you can mix-and-match:
Loading different apps for different users. If your classes all inherent from base classes, this is easier than maintaining 2 or more completely different apps.
Using a global JS variable to disable/enable certain features for certain users. This is only good if you don't have a problem with the client side loading features that are then disabled (but still seen by debuggers).
Regardless of anything, all server-side calls are checked against session variable.
check out Role-based access control. I use Yii's database-based RBAC, and have a php script that returns the rbac rules in json format when ext starts up
on the client, the best bet is to simply hide or disable functionality that is not allowed.
on the server, you should throw a 403 http error if the user is not allowed to perform a function. handle ajax exceptions in ext and check for 403s.
Related
Is it ok that static content that normally would load only on an authorized user's page be publicly requestable?
Let's say there are two routes /public-route and /private-route
public-route loads:
/public-route.html
/public-route.js
/logo.jpg
private-route loads:
/private-route.html
/private-route.js
/logo.jpg
To load the /private-route page the user needs to be authenticated. Requesting /private-route.html as a unauthenticated user will return a 401. But what about if the user directly requested /private-route.js? Is it too much to put all client side files behind an authorization check?
I'm also looking at this from the standpoint of React components. Say, a given page has certain components only available to certain types of users (guest, user, admin). Should I create 3 separate App.js'?
It depends what kind of app you are dealing with, if the app is considered sensitive it is not acceptable to allow an unauthenticated user to access any of the content that is supposed to be delivered to authenticated users only. If you are working on a professional app and are concerned about security you need to address this.
You may want to place public and private content in two different sub directories of your app which are served by different routes: for example your.site.com/public will return files and resources from /public, whereas your.site.com/private will first perform a check to see if the request is authenticated and if so return files and resources from /private. Doing so would prevent an attacker to download your private website code and resources. If anybody can create a fake/trial account and authenticate to the private section, this of course becomes irrelevant.
One thing that you may want to make sure is performing a check at the api level to verify that private endpoints are being invoked by an authenticated user, the most important part to protect in a web application is the data not the frontend source code.
The way you handle this is highly dependent on the tech you are using on your backend. With node and express for example you would typically add a custom middleware to each of the private endpoints. Some higher level frameworks can also handle that for you.
I am creating an Angular 1 SPA. Certain controls are only visible to users with certain permissions. This is based on scope variables set by server api calls.
It occurred to me that if I could access these variables through a browsers dev console, I could change their values.
I tried this for example:
angular.element($0).scope().$parent.myUserInfo.accessType = "admin"
angular.element($0).scope().$apply()
And sure enough, the admin controls popped up on the page even though I was not logged in as an admin. Is there a best practice to stop this or am I going about it completely wrong?
The authentication always have to be made on the server side.
I don't know what you are trying to do, but if the user interacts with some webService/Rest API, etc... the server should disallow such interactions.
If the accessType property of your scope is just a way for you to know which UI you should display to the user, and the authentication/session mechanism is correctly handled by the server, that should not be a problem.
However, you cannot disallow the user to play with the dev console, so you'd better handle the authentication correctly.
I am not sure if there is a way of protecting values in $scope.
But as JavaScript is executed client-side and it is therefore be possible for users to modify said code, I would always verify permissions server-side. Then it wouldn't matter if users enable the admin controls client-side as they have no permission to use the api calls.
I am new to AngularJS and trying to grasp the concept of implementing an access control layer so that some pages/menus will be hidden from certain users.
I usually implement ACL and all routes on the back-end (PHP/MySQL) but this project require me to do everything on the client side only.
We have a remote server that is in charge of authentication and upon successful login, will return an is_admin flag so that I know whether to display the additional info.
Although not likely, since Angular is also the rendering engine and is in charge of all the logic, I am afraid that users will be able to play with browser developer tools and/or other 3rd party tools and gain access to those areas (since all scripts & logic will be visible to them in the browser).
So if I do something like:
if (user.is_admin === true)
{
//display the additional admin data...
}
A user can potentially set user.is_admin = true in the browser tools and gain access.
With server side rendering such as PHP, the user will never be able to even know about these hidden areas. i.e
<?php
if ($user->is_admin === true) {...}//user will never ever see that or be able to modify $user properties
?>
Of course that the server will keep on authenticating every request so this exploit will only allow limited access, but still seems like a non secure way of hiding sections from certain users.
Am I missing something in Angular or is there a better way of doing it so that it's bullet-proof for client side hacks?
The Angular way of hiding sections is with the ng-if/ng-show/ng-hide directives, as in:
<div ng-if="is_admin">...</div>
You can't hide those divs from people who look at the source, or the resources you make available in your app. So don't provide admin data to those views.
My approach was to make an "admin" app in addition to the "standard" app and link between them. This way, the only things exposed are links to the admin site, which are blocked to non-admin users:
<div ng-if="is_admin">Link</div>
All requests to my /admin/* pages return a 401 status code if they are not an admin. The REST resources also return 401 status codes as appropriate.
(Edit: changed above ng-hide to ng-if to suppress those divs in the resulting DOM.)
I am currently learning Angularjs for an application that will need role-based access control logic. There are scenarios where the logic will be necessary to restrict access to certain pages based on your user role. There are other scenarios where I will have to restrict access to a section of a page or certain fields on a form based upon a users role. If Angularjs is a client side methodology, this seems to present a problem if I don't want the client to have any access to an item they aren't suppose to have access to.
What is the current approach for handling these scenarios from the server without interfering with Angularjs?
I know I have access to razor to restrict page section access but what problems would this present for Angularjs and would this be a good idea to mix razor and angular view syntax?
In my transition to Angularjs, I am having a problem wrapping my mind around how to handle this.
You can request views using ajax from MVC and handle any access restriction with a response.
I don't have good example now but it might set you in the right way?
Using knockout I have used a template enginge to retrieve partial views from MVC.
Same thing should work here and you can keep the access restriction on the server side (which you should).
One of the methods would require setting up a service to check if a user is authorized for the page (in angular), then setting params on a route
{
"/admin": {
templateUrl: 'partials/admin.html',
controller: 'AdminCtrl',
requireLogin: true//THIS
}
and then canceling navigation with in a controller by handling the $locationChangeStart event
(This is all shown in the article I posted below).
My suggestion would be to create views for each logical page element with individual controllers and handle access the same way as the example. Instead of per page, it will be per view.
In the case of adding/removing inputs from your forms, maybe there would be some way you could also handle this inside the service you created and then ng-show/hide the element depending on the access level.
A quick google search for 'Role Based Access Control in Angular' will pull up tons of useful tutorials/articles.
See This
And This
(more in-depth with the same examples)
You need to think about it in two parts:
Securing your API (ASP.NET Web API)
Using security/role information to present an appropriate UI (available options and routes, elements enabled / disabled etc. -> AngularJS)
You should assume that API clients are malicious - they aren't necessarily your application.
In terms of authentication / authorisation options: HTTP header tokens, such as JWT are a common option but HTTP only cookies are still a good option, especially if your clients are all web-based. The other advantage of JWT is that you can allow the client (AngularJS) to read the payload, and easily share information about what the user is allowed to access. If you use cookies you generally have to supply that information in another way (server side injection or API call, for example).
How your generate the token / cookie (and what they contain in terms of claims) depends how you need to authenticate people. It can be your own ASP.NET MVC login form, with credentials stored in a database if necessary.
You can use MVC views as AngularJS templates if you like, though I tend not to see many advantages beyond the layout.
I have two applications in my workspace, APP 1 and APP 2.
In my case, user will log in to APP 1. from there, i put a menu(or a link) to APP 2. however APP 2 requires authentication. So it will take me to a login page. i would like to eliminate that and get the current user's credentials on APP 1 and login to APP 2.
i'm looking for a simple straightforward method (but need to consider security) to login to APP 2.
what i could think of is apex_collection..i could store credentials n use it to create a login process for APP 2. however apex_collection is session based. eventhough i've set session for APP 2, it still wont read values from my apex_collection.
Does anyone have a suggestion or a solution?
All you need to do is use the same authentication scheme in both applications and set the cookie name attribute to the same value in both authentication schemes like this:
APEX will then use the same session across the two applications and the user will not have to log in again when they navigate from one to the other, provided of course that you pass the SESSION_ID in the URL.
A Few Comments on Default APEX Workspace Authentication Security
It may also be helpful to expand on an explanation of why the solution posted by #TonyAndrews works.
For any Apex Apps within the same workspace, if they use the default "APEX Application Authentication" method, they will consult the same authentication user list... so USER1 and its password is a valid login for any of the "neighboring" applications...
This may be a concern if you are hosting different clients or users that should not be intermingling with the other applications. You can also define user GROUPS in the same place as you set up each workspace user. Each application can have its own security filter that permits access by membership of BOTH user/password authentication AND membership in the appropriate access group.
Sharing workspaces may also be a problem because of the unique user name restriction of a single workspace. You can get around that by:
Defining different name-spaces for each application:
Email addresses are good: "someuser#sampledomain.com"
An app id prefix such as: SHOP_EDNA, SHOP_GARRETT, TC_KAREN, TC_MARLOWE, MY_BORIS etc.
Different name styles: first name only, first name + last initial, etc.
To keep things simple, you can always just spin up a brand new workspace: a warning however is that common user names like `ADMIN` are NOT the same between separate workspaces. There shouldn't be much concern however because apps or workspace users may have the same or different schema access privileges to the database back end.
A Word of Caution to Administrators and Developers:
When you go live with an application or multiple applications on a user-facing system, keep in mind the deployment destination (i.e., the workspace) and what else is sharing that workspace. There are some real situations where apps are not intended to be shared or accessed by other "inside" users. Be sure to read up and understand the security constraints and methods of using Default Apex Authentication security so that it's more than luck that protects your own production/live deployed applications.
I do have the similar requirement, linking from one application page to another.
Tried the above mentioned solution, but still asking to login to second application. My Apex ver is 5.0.3 and trying in same workspace.
Created new authentication schemes for each app with same cookie name and set them as current authentication. Scheme type are Application express accounts.
Setting the link as below from first app page to second.
href="http://servername:port/apex/f?p=224:2:&APP_SESSION"
Could anyone provide a solution, please?
Just an update on this.
I am currently using v21.2 and this is how I do it:
In both applications, go to Shared Components > Authentication Schemes > (Select your Auth Scheme);
Scroll down to Session Sharing and select 'Workspace Sharing';
In one of the applications (source), create a link (as a Navigation Bar List entry, for example) like f?p=173:1:&SESSION., where 173 is the target application ID and 1 is the target page.
After some research, I've found out that this feature (Session Sharing Type) is available since v18 of APEX.