I am developing a Data Modeling Software that is implemented in Java. This application converts the textual data (stored in a database) to graphical form so that users can interpret the data in a more efficient form. Now, this application will be accessed by 3 kinds of persons:
1. Managers (who can fill the database with data and they can also view the visual form of the data after entering the data into the database)
2. Viewers (who can only view the visual form of data that has been filled by managers)
3. Administrators (who can create and manage other administrators, managers and viewers)
Now, how to implement 3 diff. views of the same application.
Note: Managers, Viewers and Administrators can be located in any part of the world and should access the application through internet.
One idea that came in my mind is as follows:
Step1: Code all the business logic in EJBs so that it can be used in distributed environment (means which can be accessed by several users through internet)
Step2: Code 3 Swing GUI Clients: One for administrators, one for managers and one for viewers. These 3 GUI clients can access business logic written in EJBs.
Step3: Distribute the clients corresponding to their users. For instance, manager client to managers.
=================================QUESTIONS=======================================
Q1. Is the above approach is correct?
Q2. This is very common functionality that various softwares have. So, Do they implement this kind of functionality through this way or any other way?
Q3. If any other approach would be more better, then what is that approach?
no
no
yes
Making different clients for different security roles is a :
security hole - what if a viewer obtains the administrator version?
hard to maintain
The way to do this is:
make the data transferred to the client dependent on a security check
also make various parts of the UI visible/enabled depending on that security check
the security check is made on the server
the security check depends on the currently logged user
the user logs in on startup, using his credentials (username/password or digital certificate)
the security roles (administrator, moderator, viewer) are stored on the server side.
Then, if needed, you can extend the security model by adding:
differentiation between per-user and per-role rights
rights on specific resources
transitive rights
permissions for specific actions
But such a complex user rights and security model is perhaps not needed in your application.
I agree with #Bozho except for the following:
make various parts of the UI visible/enabled depending on a security check
You actually need to make sure that unwanted access to the data, etc is blocked on the server side, irrespective of whether the client-side UI is visible / enabled. The reason for this is that any client-side UI disabling code can be subverted. Indeed, a bad guy could even entirely bypass your UIs and reverse engineer the application-specific protocols between your client and server code.
This is not to say that you shouldn't also disable / hide parts of the UI that the user is not allowed to use. It is just not a good basis for decent security / access control.
(UPDATE : #Bozho has ammended his answer now to add server-side blocking to his list. So I now agree with it entirely. )
I agree with Bozho. Another points with the three client approach is: what if the user somehow figures out how to send the operations which isn't available in his client? What if the same user has two roles (hence is required to have two clients). And of course you will have plenty to do maintaining one client...
Related
I am working on a web project, backend is Java & Mysql, the client include web(html5) and app(IOS/Android), I have some doubt in design the account of the system.
There are 3 different types of account:
Shop, shop account will have its own website,
Customer, customer access shop/commodity via app(IOS/Android),
Admin, manage everything of the system.
My basic idea of authentication:
There will be account / role / permission table for sure, because both admin & customer will have quite complex user permission issue, customer also have different permission due to their history behavior.
I have kind decided to use Apache Shiro, due to its simplicity & distributed session.
My question is:
(1) Should I create a single account table or 3 individual account tables.
(2) Any advise on design of 3 tables:
account / role / permission ?
If in your first question you're asking how to design a database schema for three very distinct entities (admin user, customer user and shop owner), I suggest you don't combine them into a single table, because they are different concepts and will likely have different features.
You kind of answered your own question, since "ease of programming" rarely trumps business rules/logic.
Your decision to use an existing security framework, or to roll your own, should be independent of the data model for your core business entities.
If you don't want to use a managed solution like Stormpath, and haven't settled on Shiro yet, check out OACC, an open-source permission-based security framework for Java with support for hierarchical security domains, super users, permission inheritance and impersonation.
It might be a good fit for your project because:
you won't need to clutter your database design with authorization-related aspects
OACC was designed for multi-tenancy application architectures (like your project's "shops")
it allows for impersonation, which is a powerful feature if you need to support customer service representatives without giving them "admin" privileges
[Disclaimer: I am a maintainer and co-developer of OACC]
I suggest you to consider delegating all your user-management needs to Stormpath. With Stormpaht, you do not need to worry about such low-level concerns, all your data is securely managed and stored. Stormpath provides:
User management API with different SDKs: node.js, express, java, rest, python, flask.
Off the shelf Hosted Login: login, registration, and password reset.
Off the shelf ID Site to power Single Sign-On across your applications
API keys for your users, secured with HTTP Basic Auth or OAuth2
Social Login: Facebook, Google, LinkedIn, Github
Integration with Shiro and Spring Security
Integration with Active Directory and LDAP
With Stormpath you will only need to create Groups which will represent your roles. Inside your groups and accounts, you can also create finer-grained concepts like permissions using our flexible Custom Data concept.
As mentioned above, we also support Shiro integration, where you can model all your security needs with Shiro while using Stormpath as the authentication and authorization data provider. Please take a look at our Stormpath Shiro plugin and at our Sample Shiro Web App.
Disclaimer, I am an active Stormpath contributor.
To be short: you don't need role / permission tables :)
I would decide first do you really need RBAC security model? Your application looks like a perfect use case for hexagonal architecture with 3 separate isolated front-end parts: Consumer, Shop, Admin. Then I would advise to build separate authentication/authorization mechanism for each of these front-ends. In this case you are flexible to choose the best tool for the purpose (OAuth2, OpenID, LDAP whatever) and follow least common mechanism security principle. Your application doesn't look like the one which needs authorization on method level, thus you don't need RBAC.
I would design each Java object depending on its individual needs. Get clear about what you have to create. Are there overlappings in the account types? Shall a Shop account be able to buy something like (that is. extend) a Customer, or shall an Admin implement both a Shop and a Customer? Shall the address of a Customer, living in the same street as a Shop is located, change if the Shop reports the street got renamed? Does the phone number’s area code depend on the city?
If your Java objects do their job properly, think about the O/R mapping in a second step. Perhaps it will be even very different from what you may think now (just think of carrier codes in telephone numbers that require inline replacement, Packstation boths, Shops with multiple persons of contact, different address layouts in different countries …).
In general, make sure your address fields properly support UTF-8 for diacritics, greek, cyrillic or arabic addresses.
(1) Should I create a single account table or 3 individual account tables.
Yes, I think you should design a single one, as an account is going to have similar data for all 3 types.
(2) Any advise on design of 3 tables: account / role / permission ?
account: PK account_id int, FK role_id int
role: PK role_id int, account_permission enum(admin [0], customer [1])
You do not need a permission table, you may handle your permission levels in your application code, using composite design pattern, where you can have multiple hierarchical levels of admin or customer permissions. Reason for this is it's better to declare your business logic in your model code rather than database design, database is there to persist data with as optimised and normalised state as possible. I suppose you can then use dependency injection to your composite permission hierarchy depending on customer behaviour, which needs to be held in the database under a table, ie named customer_behaviour, with certain columns "ticked" as they behave certain ways.
Hope this helps.
I have a SQL databse on the internet which has information
I need my Android app to be able to access that information
The app needs to know the username and password of the database
How can it know?
If i code it in, anyone can get it
In general, databases should not be publicly accessible, nor should they be directly accessed by a user application, for several very good reasons:
There is generally no easy way to implement row-level access control. Views and triggers can only get you so far - in general application-level users do not map well to database users, since the latter usually have access to far more data than the former should have.
The DB clients are tied to the actual database schema. Having clients not under your control like, say, an Android application is a very good way to tie yourself up in ways that would disallow any and all future development.
Having a DB port open to the world is not considered by any means secure. Any potential security hole would give straight access to all of your data. The MySQL security guidelines explicitly warn against opening the DB port to the internet.
There is no way to protect the DB credentials or the data from a sufficiently determined and knowledgeable user. If your application can access something, so can they.
Database access protocols are mostly designed with local-area networks in mind, rather than the inherently unreliable nature of the Internet. Even encryption and security are often more of an afterthought...
The standard way to approach this issue is to create an intermediate web service with separate user accounts and a restricted set of operations on the data. The web service would let each user access only the data that relate to them, and even that indirectly. This approach separates the data from the user application layer, allows you the flexibility of storing and accessing your data however you wish and provides an additional layer of security for your DB.
I want to make my web application able to work offline and as soon as it becomes online or gets connected again, then it should be able to transfer the modifications made by user in offline mode.
I have seen Google Gears as an ideal solution for my problem, which is not recommended to be used as it is now deprecated.
What is a good way to make my application work offline, both in terms of technology to use and application design?
Gears is deprecated because the HTML5 standard allows for equivalent features to be present in compliant browsers.
With respect to your current problem at hand of handling offline web application access, you can look into the support offered by HTML5 for offline web applications via support for client-side SQL database access, and the client-side application HTTP cache.
The features will have to be used in conjunction, as the client-side database access will allow for storage of data (generated when the application is offline) in a structured format, while the offline application cache will allow for caching of HTTP responses from the server; you should not be caching responses that are dynamic in nature which depend on any user-provided inputs.
The details of the proposed APIs can be found in the W3C HTML5 specification, which is in draft at the moment, although it appears that certain user-agents have already implemented this feature.
Firstly, you will need some form of offline storage. HTML5's capabilities are the successor to Google Gears, as stated on the google gears developer blog; essentially, the purpose of Google Gears was just to push the development & subsequent adoption of HTML 5 features.
Specifically you should be looking at the HTML5 offline (here's a tutorial) APIs, and the Storage APIs may also come in handy (relevant tutorial).
With regards to design, you will essentially need to maintain your complete web application state client side, and then send over the differences (i.e. update the server-side state) as soon as the connection to the server is available again.
Off the top of my head, there's 2 simple ways to design this:
Explicitly maintain separate application states for the client and server. Essentially, when the user takes an action, it's applied to the client application state first, and then at specified intervals (and/or triggers, e.g. the user clicks the save button), the client sends over the differences between the last known state of the server and the current state of the client. This is probably best suited to highly interactive web applications, and I suspect Google Docs works on this kind of design. Depending on your application (if "conflicting changes" can occur), you'll need to also account for merging application state: do you override with the last received client state, or do you intelligently try to merge? (you'll have to decide which makes more sense for your particular application.)
Record user actions while offline, and replay them once the connection becomes available again. You essentially implement the Command design pattern, and have both your client-side code and server-side code able to handle each command. The client-side code always handles each command, and while the connection to the server is available, your client side code also sends off the commands to the server. You'll probably want to implement some batching, to avoid continual requests to the server, and also some roll-back functionality when requests to the server fail (e.g. conflicting changes). This ends up looking more or less like GMail's main email managment user interface, where you can undo operations.
This has not much to do with J2EE, but rather how you code your web-client. One possible solution would be to use a javascript client that does save the data in the local storage introduced with html5 (see http://diveintohtml5.ep.io/storage.html ). That is also basically the reason why google gears was stopped ...
I need to choose an authentication method for an application installed and integrated in customers environment. There are two types of environments - windows and linux/unix. Application is user based, no web stuff, pure Java. The requirement is to authenticate users which will use my application against customer provided user base. Meaning, customer installs my app, but uses his own users to grant or deny access to my app. Typical, right?
I have three options to consider and I need to pick up the one which would be a) the most flexible to cover most common modern environments and b) would take least effort while stay robust and standard.
Option (1) - Authenticate locally managing user credentials in some local storage, e.g. file. Customer would then add his users to my application and it will then check the passwords. Simple, clumsy but would work. Customers would have to punch every user they want to grant access to my app using some UI we will have to provide. Lots of work for me, headache to the customer.
Option (2) - Use LDAP authentication. Customers would tell my app where to look for users and I will walk their directory resolving names into user names and trying to bind with found password. This is better approach IMO, but more fragile because I will have to walk an unknown directory structure and who knows if this will be permitted everywhere. Would be harder to test since there are many LDAP implementation out there, last thing I want is drowning in this voodoo.
Option(3) - Use plain Kerberos authentication. Customers would tell my app what realm (domain) and which KDC (key distribution center) to use. In ideal world these two parameters would be all I need to set while customers could use their own administration tools to configure domain and kdc. My application would simply delegate user credentials to this third party (using JAAS or Spring security) and consider success when third party is happy with them.
I personally prefer #3, but not sure what surprises I might face. Would this cover windows and *nix systems entirely? Is there another option to consider?
Go with LDAP. Access is very easy, and the only parameter you need is the LDAP Server (and ActiveDirectory is one). If the user exists and the password is correct, he will always be able to log into the LDAP server.
Here's a scenario:
I have a java front end (RCP/SWT) app which currently has no authentication support.
I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.
Approach 1
Create a 'Security' webservice that
the thick client would invoke, on startup.
The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.
Advantages:
This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.
Approach 2
KISS (Keepin in yea.., Simple)
User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
Have the thick client query the webservice and let the webservice handle the entire authentication process.
I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.
I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.
Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.
If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.
After knowing that your requirements impose some limitations, take a look at this network classloaders article.