I'm looking for a way to pull user (eg. inetOrgPerson) information in a federated way. For the most part, this information will come from LDAP but could come from secondary systems. I've looked at things like Jasig's Person Directory (married to Spring and we don't use it) and ArisID (no examples of use, yet). I'm working inside of OSGi and would like something that is already bundled but am willing to bundle things myself. What other IM libraries out there should I consider?
I never found anything to fit my needs. I created an OSGi bundle to which services get registered to aggregate data. The services are defined by the interface they implement to look up users in different ways and can draw the data from any source. The information is then cached by the aggregator while the session is valid.
So, in short, I didn't find anything out there that is simple enough to fit this.
Related
I have been poking around the Internet for some time looking for more information on configuring Sling Resource Resolver mappings. From what I found online and my experience there are currently two methods accomplishing this in AEM.
Through the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
OSGi property resource.resolver.mapping
Through the resources specified by the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGI property resource.resolver.map.location
The Sling documentation on Mappings for Resource Resolution and the AEM documentation on Resource Mapping both seem to suggest that using the method (2) that makes use of the property resource.resolver.map.location is the recommended way given that it is the only method explained by the documentations.
I'd love to clear this up and gain a better understanding on this topic. I think most of the online resources on this subject lack of depth in explaining the differences in both methods and the benefits in using one versus the other. More detailed insight, explanations and practical illustrations on this topic are highly welcomed.
Thanks
I also can't give an answer. But if you look into the code at MapEntries#doUpdateConfiguration (line 428), then you can see that the following entries are finally merged into the same internal lookup-map. So technically there is no difference.
resource.resolver.virtual
resource.resolver.mapping
resource.resolver.map.location
See code at:
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/master/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java
My Understanding
In my understanding at least since Day CQ 5 the recommended way is to use resource.resolver.map.location. It is the most flexible way. The others are probably still there for historic reasons.
Large Multi-Brand / Multi-Teams Projects
Another good reason for /etc/map is, that large projects with multiple teams and brands have to avoid global OSGi configs (have something like Unilever in mind). Therefore many other OSGi configs have also an alternative way to configure it:
by a config-factory (Sling Service User Mapper / Sling Service User Mapper Amendment)
by a per-service config (sling.auth.requirements in the Sling Authentication Service)
or by a global content structure (your example with /etc/maps)
In such cases always prefer the variant, which allows multiple teams to independently provide their part of the config. In your case the teams could provide different sub-trees under /etc/map
PS: I'm even not sure, if regex are working in the OSGi configs. This speaks for /etc/maps too.
I wanted to use the OSGi User Admin service for security but I could not get enough resource about it.
I want to authenticate certain bundles that will be installed in the system and represent them by User-Objects after authentication. So that I can later use these User-Object for authorization.
I have 2 questions:
Since I have more than one user, how can I know which bundle is calling a secured method? (I don't want to pass the user object as a parameter to every method I want to control).
How can I relate the bundles with the User-Object representing them?
I want to have one bundle as an entry point that will authenticate all these other bundles and have control over them. But I couldn't even find anyone mentioning using User Admin service. Is there another option for OSGi security besides CPA? I would like to use this to secure my console as well.
That's quite a few questions rolled into one. Let me try to answer them all.
First of all, the UserAdmin service is specified in the OSGi compendium. There, it explains how users, roles, etc are defined and how you can use the service to answer questions like "does this user have role X"? What that does not tell you is how to use this service as part of a security solution. That's up to you.
Regarding question 1, which is not an OSGi related problem (but rather a generic one in Java applications), there traditionally have been a few methods of passing on a "context" to a method:
Making it an argument to each method (which you do not want to do).
Storing it in the ThreadLocal context (which is fairly popular in JavaEE, but has its downsides if your application delegates work to threadpools that might or might not pass on such a context correctly).
If this is all about security for services that you implement yourself (and not third-party ones) you could use the ServiceFactory pattern in OSGi to give each client bundle it's own context (and embed the User object in there; for examples look at the LogService implementation in Felix, which uses that mechanism to add a bundle.id to each log message).
Sometimes it also makes sense to embed the context not in an extra parameter to your methods, but as part of some existing object (so effectively you are then associating the context with specific objects, which might or might not make sense depending on your domain).
Another option would be to use the Apache Felix Dependency Manager to intercept the services you want to secure (with an aspect) and, in the aspect, figure out what bundle is calling, and do the proper security checks (probably requires a more detailed answer if you want to give that a go).
Regarding question 2, bundles have a symbolic name that identifies them. You could use that to associate a bundle with a User. There are other options, but this is the most obvious one.
Regarding your question about options for OSGi security, I would say ConditionalPermissionAdmin (and the older PermissionAdmin) is the only solution to address security within the OSGi framework itself, if you want to specify what specific bundles can and cannot do in terms of importing packages, using services, accessing the filesystem, etc. You would have to write your own custom permissions if you want to integrate this with UserAdmin.
Finally, the secure console is yet another thing you need to address yourself. You might be able to find some building blocks as I know there have been people implementing some role based access (David Bosschaert comes to mind). However, the console is a complex and powerful thing, so answering this question alone takes more than a simple SO question because it depends what and how fine grained you want to implement this.
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'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.