I'm currently looking into securing jax-rs web services.
The following URL is very interesting: https://docs.oracle.com/cd/E24329_01/web.1211/e24983/secure.htm#RESTF256.
I am especially looking at the annotations-based security of web services. Defining per method the roles that are allowed looks very straightforward.
I have however 4 questions related to this topic:
defining and mapping roles
I'm wondering: where does one define the roles of users and how does one make the mapping of users to roles when using annotation-based security?
If someone could point me to an example with code, that would be great, I'm not having a lot of luck finding one.
Libraries/frameworks
Are there any libraries/frameworks that you know of that could be used for securing jax-rs services? I don't have the impression e.g. that Apache Shiro is really suited for web services? I would prefer not using Spring security, it's a bit too heavy for what I'm doing.
Database design
Also, for an authentication/authorization scheme using RBAC, with users having roles and roles having assigned permissions, how do you design this on a database level?
Permissions
When looking at the RBAC principle, you have permissions assigned to roles. However, using annotation based security, you only define "access" to methods on a role level. How do you check if a user has permissions? Or do you just use roles and ignore permissions altogether when using an RBAC principle?
Thanks for any input you can provide!
UPDATE1: Am I correct in assuming that, if you define your users and what roles they have yourself in a database instead of e.g. in web.xml, that it is probably easier/better to use SecurityContext for checking if users are in roles, instead of web.xml or annotations?
This would allow you to use your own securitycontext object which can make calls to a database for validating role membership?
j_security_check makes it easy to load users from a ldap server. It saves me a USER table. It's like user-management task is separated from the system.
But the problem is, in a production system with sophisticated requirements, a lot of data is associated with user id. What I expect from the user-management is not simply login/verify the password. For example I have an USER_MEMBERSHIP table, to record what kind of membership a specific user has purchased. If the user logs by j_security_check, how can I list users belonging to a specific membership? Eventually I wound up creating another USER table in my database, and fill in user info the first time they get logged in. If I have to do this, why should I use j_security_check anyway? Why not just verify the password in my database, and cut off the complicity of form_login/ldap ?
I'm getting so confused here. Is it fair to say j_security_check is for simple systems only? Is it recommended login machinism for sophisiticated Java EE applications?
Thanks in advance.
J_security_check is part of Container Managed Authentication, which assumes the entire burden of ensuring users are logged in, associating them with roles, and enforcing role-based access to various parts of the application as defined by security entries in web.xml. If you don't use CMA, you are condemned to reimplement all this stuff yourself. It's possible; it's error-prone; it's repeating work that has already been done. And tested.
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 created one group on web-logic server, now i want to add user in that groups(they are configured on LDAP Server).
how can I achieve the same. or is there any way I can get all list of LDAP users or groups through some java code.
You're actually making life harder for yourself than it needs to be here.
A user's group memberships should be defined in the same security realm as the user themselves - you can't get part of the subject from one place and part of it from the other, at least not without creating a custom security provider as far as I'm aware, and that's way more effort than its worth.
If the users are defined in an external LDAP server, this is where the group membership should also be configured.
A possible alternative depending on what you're securing would be to use role-based security configuration, but even then you still want something to determine membership in a role, and that should typically be a group.
Security configuration should always be based on groups rather than users, otherwise maintenance will become very painful.
I'm interested in the best practices of using LDAP authentication in a Java-based web application. In my app I don't want to store username\password, only some ids. But I want to retrieve addition information (Name, Last name) if any exists in an LDAP catalog.
My team uses LDAP as a standard way of authentication. Basically, we treat LDAP as any another database.
To add user to application, you have to pick one from LDAP or create it in LDAP; when user is deleted from application, it stays in LDAP but has no access to application.
You basically need to store only LDAP username locally. You can either read LDAP data (e-mail, department etc) from LDAP each time, or pull it in application in some way, though reading it from LDAP is probably simpler and smarter since LDAP data can change. Of course, if you need reporting or use LDAP data extensively, you might want to pull it from LDAP (manually or with batch task).
The nice thing is that once a user is disabled in LDAP, it's disabled in all applications at once; also, user has same credentials in all applications. In corporate environment, with a bunch of internal applications, this is a major plus. Don't use LDAP for users for only one application; no real benefits in that scenario.
For general best practices with LDAP, see "LDAP: Programming practices".
If you have more than one web based application and want to use LDAP authentication then a prepackaged single sign on solution might be better than creating your own LDAP authentication. CAS supports LDAP authentication and can pull back the data you need for your application.
At my college we actually have implemented CAS as a single sign on against our Active Directory server. We also utilize CAS to authenticate our J2EE applications and are working on using CAS to authenticate our PHP applications.
We use AD to hold the users for the domain. There are certain OUs for based on the type of user. The users each have a unique ID which happens to be their student/employee ID, so applications can use that as a primary key in their databases. We have a database driven authorization method for our PHP applications. Authorization for the J2EE application comes from a value in LDAP.
Good luck with your application.
So, you want user to enter ID only, and then grab the rest of their info from LDAP? That's quite easy.
Create LdapInitial context and connect to LDAP
Do a search for the ID (it should be stored as some attribute value) -- e.g. (&(userid=john)(objectClass=user)) -- which means "userid=john AND objectClass=user"
SearchResult object would contain all Attributes (or the ones you asked)
Some LDAP implementations (notable MS ActiveDirectory LDAP) do not let you connect with anonymous user. For those you need to have a technical userid/password to connect.
As said above, LDAP is normally makes sense when you have many applications.
P.S. For feeling what LDAP is try Apache Directory Studio.