I'm looking at creating a decentralized role-management system which integrates with Java EE roles. Does anything like this exist?
Example use cases:
System A is a limited-access system which uses corporate roles. John joins a team, and requires SYSTEM_A_READONLY to perform his function. He logs on to the decentralised role-management system, and puts in a request for SYSTEM_A_READONLY. Bill is the administrator for System A, and receives a notification that John has applied for this access. He can then log on to the same system and approve the request. John now has access to System A.
System B is a sensitive customer management system. It has 1 role for each company that it serves. Currently it has SYSTEM_B_CLIENT_FOO, SYSTEM_B_CLIENT_BAR, etc. Greg is the administrator for this system, and he is notified by the sales team that TNT have signed on as a customer. He logs on to the role management system, and adds the new client. Web Application C (hosted remotely, but still using corporate roles) detects the new role, and adds it as an option for it's users.
Hope that makes sense. I've looked into making it myself, but it seems like a requirement that must be quite common.
I don't think anything like this exists. The requirement indeed seems quite common, but I think appearances are deceiving. Every company, for ever (range of) application(s), will have very specific requirements concerning the interface to administer users and roles.
Depending on the requirements, it may also be reasonably simple to set up. If 'putting in a request' simply means 'an email is sent to the admin' and 'adding the client' means logging in using a simple, CRUD-framework generated, admin and filling out a form, then you are already done.
You could look at Apache Shiro http://incubator.apache.org/shiro/ although I'm not sure it's either ready for prime time or completely does what you're looking for out of the box.
You could develop the authorization components using Spring Security, specifically by implementing your own AccessDecisionVoter and UserDetailsService. The entities, persistence and web ui components are pretty straightforward, you could do those in whatever framework you're comfortable with.
There are some products out there to help you - things like crosslogix from bea.
These are generally logic decision engines that let you craft complex rules that allow for things like roles and permissions to be nested and hierarchal. they also (generally) allow for parameterized permission checks like user is in role ACCOUNT_APPROVER if it's the last week of the month.
"Detecting new roles" generally comes as a by-product of having the centralized system - i.e everything just queries it, and the API is very fast specifically to make querying a 'cheap' operation.
What they are generally not so good at (I guess as they perceive it's not in their space) is the workflow around approving access to these roles. They'll generally give you a console ( & an API ) to modify them, but leave the approval workflow up to you.
As the previous poster said - the problem with the approval bit is that it tends to be very company specific - so it's often left as an API.
In short - something like crosslogix would do half of what you need - the decision logic, and this, and most products give you a simple uber-console to manage the permission logic, but if you wanted company specific logic for approvals - you'd probably have to skin a website on top.
-ace
Well, to me, such a system exists and is called LDAP (LDAP groups are typically mapped to J2EE roles). But I admit that LDAP engine doesn't provide all the facilities and workflows that you mentioned. Actually, my experience is that these are specific to each company (maybe because of the lack of "universal" tool) and, most of time, companies I've worked for had custom admin applications and custom APIs to interact with it from applications.
We have used something very similay to what you are asking . Icefaces has renderonUserRole propery for their components , this can be combined with Spring Security to achive part of what you need. See this
Related
I'm so worried about people logging confidential information to server logs.
I have seen server logs in production. Some developers are accidentally logging security related
information like password, clientId, clientSecret etc.
Is there any way, like Eclipse plugin or any tool, to warn developers while writing their code?
`ex : log.info("usernam = " + username + "password = " + password) ;` //
Warn that confidential info is getting logged.
I have done some research... I have seen tools like sonarLint and FindBug
but those plugins are unable to solve my problem.
SonarLint offers the rule S2068: Credentials should not be hard-coded, which targets the use of hard-coded credentials, and it seems close to what you are trying to achieve, though it may be not enough for your needs.
As stated in other answers, however, identifying such security holes can be ultimately hard and strong code reviews is certainly a good move to reduce the risks.
Now, if you really fear about usages of loggers, already knows potential issues, and what data could leak, I would suggest to write your own Java Custom Rule for SonarQube.
Custom rules are supported by SonarLint and can be applied at enterprise level once the Custom Plugin containing it is deployed on a SonarQube server. This solution would allow you to explicitly define what you want to target, and fine-tune a rule depending on your needs and enterprise specifics. Writing such rules is not hard and documented in the following tutorial: Custom rules for Java.
There are many different ways how security holes can appear. Logging data to the browser console is only one of them.
And to my knowledge, there is no tool that can detect those security issues automatically. It is the responsibility of the programmer to not expose private user information on a page.
In this case the advice is: Never log passwords (especially unencrypted ones) to the browser console! Instead, encrypt your passwords in the database with an algorithm that can't be decrypted.
Another approach is to create a custom log appender that looks for certain tell-tale patterns (e.g. works like "password" and "passwd") and obliterates the messages, or throws an error.
However, this could be dangerous. If the bad guys knew you were doing this, they might try to exploit it to cover their tracks or even crash your server.
I wouldn't hold my breath for some out-of-the-box solution on this one. Beyond your own logging, you also have to be concerned about the logging done by your dependencies. That said, you have two areas to work on: what goes into the logs and who has access to the logs.
As far as what goes into the logs, your best tools to combat this problem are education and collaboration (including the aforementioned code reviews). Start with writing a list of non-functional requirements for logging that includes security that addresses what to log and how to log (markers, levels, sensitive parameters, etc). I recommend working with colleagues on defining this list so it doesn't become known as "Ravi's logging crusade" instead of "something we really need to do".
Once that list is defined and you get your colleague's and/or management's buy-in, you can write wrappers for logging implementations that support the list of non-functional logging requirements that you assembled. If it is really necessary to log sensitive parameters, provide a way for the parameters to be asymmetrically encrypted for later retrieval by a root account: such as the encryption key stored in a file only accessible by root/container. For management, you might have to spend some time writing up value propositions describing why your initiative is valuable to your company.
Next work with whoever defines your SLDC - make sure the change to your SDLC is outwardly communicated. Have them create a Secure Coding checklist for your company to implement with 1 item on it that says: All logging is implemented using OurCompanySecureLogger. Now you can start working on enforcing the initiative. I recommend writing a check on the build server that looks at dependencies and fails the build if it finds a direct reference to log4j, slf4j, logback, etc.
Regarding the other half of the problem, work with your SysOps team to define rules of Segregation of Duties. That is, software engineers shouldn't have access to the servers where logging is being performed. If you're not staffed well enough at this point to support this notion, you might have to get creative.
May be you should try Contrast tool. Its good one and we are using it since long.
It takes care of all updated owasp top 10 issues.
Quite good for finding security holes in enterprise applications.
Their support is also good.
I'm going to implement Access Control List using java.security.acl for displaying permitted items in a user account page.
For instance, there are some users and user groups and the users as well as the groups can have some permissions. There are some links in the user account page, they are add, delete, edit and view. The user account page is same for all users, but the links (add, delete, edit and view) will be displayed differently according to the user permission.
I can achieve this task with collection framework. I'm going to implement it with java.security.acl in an initial development of an ERP (enterprise application). I want to know whether there will be any security loop hole or something with this implementation (even in future). Why I doubt is that when I visited a site which says The use of this package is not recommended.
Is there any advantage of using this package instead of collection framework? Is there any case which needs the implementation of this package in a Java EE project? All your recommendations, suggestions and advices are welcome.
I guess it might be too late to provide an answer, but I came across the question and I had just been reading up things on ACL.
First of all, the classes in the java.security.acl have been superseded by the classes in the java.security packages As mentioned here. As a general policy, while doing new development, I prefer to use only the latest APIs.
Second; the classes in the java.security packages are probably meant only for securing the system resources like file I/O and network I/O or printers and so on. Securing your application's domain object is not what they were meant for, as mentioned in the last paragraph here.
You could look into spring-security-acl for this purpose, or roll your own solution (as you mentioned in the question).
Is there any advantage of using this package instead of collection framework?
Well, depends on what you are trying to achieve, but, in your case, the question is not relevant.
Is there any case which needs the implementation of this package in a Java EE project?
No, not required unless you need to access resources on the client-side, or planning to use custom socket-based communications with SSL/TLS.
I need to build an application that will be based on user roles and preferences. Similar to facebook or google widgets, where a user can add/remove apps. In additions, there will be preconfigured apps loaded automatically.
Is there a generic tool/framework that would facilitate this?
Haven't seen a generic tool for that, but...
....I have seen this case implemented ("reinvented and reprogrammed") several times. I have see that some of the newest libraries and frameworks, have their own access rights implemented (example: asp.net).
You didn't mention or tagged if you already choose an existing programming framework, for your application, maybe you already have in mind a framework, and maybe that framework has some libraries to control how and what modules, can a user access.
Usually, a set of libraries for this, is separated in two sections.
One section is a data access layer, that store the users, roles and access rights for each role or user. Usually is a set of tables in the application's database. But, can be also some configuration files, like XML.
The other section of code has to do with the logical or user interface layer, and that is very specific to the programming language and programming framework you are using, that's why I think there is not a generic tool.
I want to assign ITIM users, roles/groups so that I can block them from operations they are not authorized for.
This concept is same as j2ee security roles.
How to create roles/groups in ITIM? How to assign it to users in ITIM?
You need to try develop the workflows into iTIM and try to align it with the current workflows involved. In fact what you are asking cannot be just explained into a single answer as iTIM assignment of roles goes through a number of other processes. Still you can refer a few IBM documents available on same. Recently we had developed a similar thing and had to put a lot of time/research onto this.
I'm designing the security subsystem for a new product. The system requires the following:
Complex user/group/permission model, both service-level and domain-level (ACL)
Administration UI for the above
Rules performed upon user actions (account disable on failed login, password complexity requirements, etc).
Before going ahead and implementing most of the features that Spring Security (2.x) lacks, I was wondering if anyone is familiar with and can recommend a package that may already implement / support these requirements? ideally JAR + WAR that can be dropped into the project and support everything off-the-shelf.
Thanks
Not exactly what you are looking for, but you might be interested in checking out jSecurity. It is a well thought out security framework that handles authentication, authorization, and fine-grained permissions. But from what I can gather, much like Spring Security, they try not to make assumptions about how this data is stored and organized. (I haven't found, for example, a reference implementation for User, Roles, Permissions, etc. in a database.)
Note that the JSecurity project has permanently moved to the Apache Software Foundation and is now known as the Apache Shiro project.
Interesting you asked, I also have a very similar requirement and have been searching this for a while. I gave up and started doing it myself and have some decent progress in the last 2 weeks. Currently I have support for domain ids that are not necessarily Long, it could be anything such as a wild-card string to denote a group of things that could be granted to an authority (ROLE, GROUP, USER) or a String id or even a long. Multiple permission types each with their or sets of permissions can be defined and these permission types could be assigned as supported to a secured entity and the instances be protected by them, so you don't have the limitation of a maximum of 32 possible permissions across the system. Also you could use any actual or virtual entities in the ACL configuration. All this is based on the new (3.0.0.R1) of Spring security with method expression support and it works fairly well. The whole thing uses hibernate so you can take advantage of the transparent persistence and distributed caching. There are lots of rough edges, but being a proof of concept its expected. Anyways let me know if you are interested and we could collaborate to make this useful to us and probably others too.