Web user account management components - java

I need to create user account registration / login / management components for a Spring backed web application. I'm intending to use Acegi to help with the authentication side of things. Is there a framework / set of components that can help with the boilerplate account validation e-mails, forgotten password handling etc functions?
Related but not the same as this question, and almost exactly the same as a question on the SpringSource forum, that was asked several years ago.

Beyond Emmet, there really doesn't seem to be a good solution here. Part of the problem is the lack of consensus and standards, as observed by the University of Cambridge security researchers: -
Password implementation is a very common task implemented by thousands of websites, but standards are doing little to improve the process. Until good standards become available, their role is partially fulfilled by industry de-facto standards or community-driven guidelines which remain scattered on the Web amidst much noise.
Passwords in the wild, part III: password standards for the Web
(The rest of that blog series is very interesting and useful in this area).
Some of the functionality is provided by Spring Security (e.g. Password encoding components).

Take a look at the Emmet project. Providing a user management subsystem for Spring-based projects is one of its two aims. (The other aim is to provide SpringSecurity enhancements and potted wiring files to support Shibboleth, various kinds of "hybrid" login schemes, and other things.)
(Disclaimer - I'm the primary author of Emmet.)

Related

Is Oauth2 a suitable choice for our needs?

1 - Current situation
We've got a REST API (coded with the Play framework 2.5 in Java) and four front-end interacting with it (two web apps: a back office and our site coded with React, and two mobile apps: Android and iOS).
Everything is working correctly, but without user management.
2 - What we want to do
We would like to add user management with two roles: user (can sign up and log in to our site and our mobile apps) and admin (can do everything a user can do plus can log in to the back office). In other terms, administrators can use all web services whereas users can only use some of them.
Firstly, users have to be able to sign up with email and password.
In a second time (this is not part of our MVP), we would like to give the opportunity to register using a Google or a Facebook account.
3 - Technical choice
After reading a lot, we think that an authentication whose authorization step is taken care of by Oauth2 is a suitable choice.
But, during our research, we found articles that have made us hesitate, with sentences like theses ones:
"You should only use OAuth if you actually need it. If you are
building a service where you need to use a user’s private data that is
stored on another system — use OAuth. If not — you might want to
rethink your approach!"
"To be clear, OAuth 2.0 at the hand of a developer with deep
understanding of web security will likely result is a secure
implementation. However, at the hands of most developers — as has been
the experience from the past two years — 2.0 is likely to produce
insecure implementations."
We're not going to implement Google or Facebook authentication right away and don't have a "deep understanding of web security", so we question the relevance of choosing Oauth2.
4 - Implementation
We've understood the way Oauth2 works and are not afraid by the implementation of the client side, it seems straightforward (and many projects exist to facilitate its implementation).
On the contrary, for the server side, we will have to create an authorization server and it scares us a bit because we don't know how to do. Implement the whole by ourselves seems to be a fairly substantial and difficult job (and we didn't find any example using Play Java), we're scared to make a mistake that would create a security hole and don't want to reinvent the wheel. We've found some tools like Apache Oltu or Spring Security (that I've used in another project) but we're not sure if they're suitable for what we want to do.
5 - Questions
Is Oauth2 really a suitable choice for our needs?
If we choose Oauth2, what should we do about implementation? Trying to do it by ourselves? Using a tool like Apache Oltu or Spring Security?
Thank you in advance for your answers!

Necessary and essential features that java framework must include for testing,development and production

May be this question broad and hard to answer at current moment
But,when i went through different frameworks emerging by one after another like
Hadoop Distributed File System
HBase,
Hive,
Cassandra,
Hypertable,
Amazon S3,
BigTable,
DynamoDB,
MongoDB,
Redis,
Riak,
Neo4J,
Stripes,
Wicket,
Compojure,
Conjure,
Grails,
JRoR,
JSF,
Lift,
Netty,
Noir,
Play,
Scalatra,
Seam,
Sitemesh,
Spark,
Spring MVC,
Stripes,
Struts,
Tapestry,
VRaptor,
Vert.x,
Stripes,
Tapestry
OpenXava
It is always buzzing me.
Each framework has some unique features.Each one promises to solve some particular testing,development and production need with respect to increasing no of users ,data expansion,distributed computing and security ,performance and many more .
But,many functionality is common on them .Striving for unique some functionality we have to shift from one framework to another As,a java developer i would like to have following features included in one framework
like
Out of box support for testing for unit and integration testing
Fast prototyping
Distributed multithreading,caching,logging ,session management ,moduaralization
Security extension
Framework extension
Easily integration with big data .
Distributed data computation
Asychronous operation
High performance
I would like to know what other features others really want to have in one framework ?What others developer really want to have features included in one framework .What are the necessary and essential featues that every framework must include .Please share yours idea.
The reason they differ is because there is no consensus on these matters. Depending on your background and expertise the answer will be different. Every project was started knowing full well what the alternatives were and not being content with them.
This question is useless I'm afraid.
I think XKCD describes it well (replace standard with framework):
There is simply no way given an enough complex problem to solve it for all use cases and users.
The key to understanding is not in how much common is there about all those frameworks but in that most of them cover only part of needs. For instance, Hadoop and Stripes do nothing in common. Only few frameworks claim they cover everything (Java EE and Spring in fact) but in reality they just try to collect several unrelated technologies under one brand name.
The real domains are: presentation layer, data access layer and (arguably) something else.

How to implement or integrate single sign on with SAML and Shibboleth

We have two separate products, both including web app and server.
We want to implement Single Sign On for both of them, so when a user has logged into one product, he can automatically access resources in the other product belonging to him.
I have explored a little bit and find SAML is a good approach that we can take, but we are not sure how we want to proceed.
Is it a good idea to implement our own Service Provider? I have looked at Shib SP, but looks like if I want to integrate it into my products, it won't be that easy too.
So I am just looking for some suggestions from people who have encountered a similar problem before.
Another question is what resource that I can study if I need to implement a SP using OpenSaml? Looks like there is not a lot of tutorials or examples that I can refer to.
I would also be really appreciated if anybody can just point out some big procedures or components that my own SP need to contain.
EDIT 1:
Just try to provide more details about what I want. We have two separate products. Currently we are able to externalize user database. For example, our products can be configed to connect to LDAP server or any other external user DB as long as they implement a service properly.
Now our goal is we want SSO for both of our products. One scenario is we have our own SP component(either implement or integrate) in both products. Customer may have their own IdP. With some configuration, our SP can connect to their IdP, and do authentication from there, and user doesn't need to login twice to access both products. Of cause, we can provide an out of the box IdP if customer doesn't have it.
The biggest difficulty with Shibboleth is that it is, effectively, a reference implementation of the SAML v2.0 specification.
For most routine installations, though, you actually need very little of the SAML spec to enable a couple of web apps for SSO.
But since Shibboleth implements the whole thing, with all of its capability, it can be a bear to configure.
We did a project with Shibboleth (and it was admittedly an on the edge use case), and, for me, a SAML novice at the time, it was really a chore to get everything up and working.
For our next stab, I looked at the SAML spec for SSO via the Web Profile. If you read it, it's actually quite straightforward for this limited use case. And we decided that instead of using Shibboleth again, we'd write our own IdP and SP using the OpenSAML libraries.
Could we have got Shibboleth working faster? Probably. But I don't think we'd have the understanding of it that we do of our own. A bit of Not-Invented-Here, sure, but this stuff is confusing enough when you do understand the software and vocabulary, much less when you don't. And SAML is chock full of new vocabulary.
You can also consider using SimpleSAML as an IdP and writing your own SP for your web apps. SimpleSAML is in PHP, but it's a bit more user friendly. You can just treat it as a self contained apache service.
I will say that our SP weighs in at around 1000 lines of javadoc'd code, but it's mostly wiring OpenSAML stuff together and some utility stuff. In truth it's not that scary. Be prepared to really enjoy reading signed XML blobs though.
It is frustrating that this really isn't simpler, but it's a bit of a chicken/egg thing regarding adoption etc.
And if none of that suits you, you can look at OAuth2 and some of its profiles.
If you only want to implement SSO between 2 products, I think yes, building something from the scratch is easier. If it's Java, Shibboleth's OpenSaml is a very good lib.
As you begin to implement more stuff, and some complex scenarios, going for something already built is the best choice. You should also be aware of several stuff you'll be likely to write on a per-system basis (e. g. assertion generation, xml-dsig, validation, etc).
At a glance, it might seem like the already built products are way too complex or difficult to scale or adapt to your particular needs. But your dev effort writing connectors and implementations can be rewarded when you feel like exploding all of the SAML capabilities.
It'd be very helpful though, if you can explain with more detail what do you want to achieve; I feel your question is quite open...
I don't have personal experience with Shibboleth Service Provider, but I am currently developing architecture which uses Shibboleth IdP, Shibboleth Discovery Service and Guanxi Service Provider. Integrating lightweight Guard module from Guanxi Service Provider with Java webapp is a piece of cake and you can easily obtain Shibboleth based architecture without writing your own modules. There is localhost tutorial for setting up Guanxi SP, just skip the parts about Guanxi WAYF and IdP and use Shibboleth components in their place.

High level Java security framework

What security framework do you use in your Java projects?
I used Spring Security and Apache Shiro and they both look immature.
Spring Security flaws:
no native support for permissions;
no ability to use explicitly in Java code (sometimes it's necessary);
too much focused on classic (non AJAX) web applications.
Apache Shiro flaws:
bugs in final release (like the problem with Spring integration);
no support for OpenID and some other widely used technologies;
performance issues reported.
There is also lack of documentation for both of them.
Maybe most of the real projects develop their own security frameworks?
As for Apache Shiro:
I'm not sure why you've listed the things you did:
Every project in the world has release bugs, without question. The big key here however is that Shiro's team is responsive and fixes them ASAP. This is not something to evaluate a framework on, otherwise you'd eliminate every framework, including any you write yourself.
OpenID support will be released shortly in Shiro 1.2 - maybe a month out?.
What performance issues? No one has ever reported performance issues to the dev list, especially since the caching support in Shiro is broad and first-class. Without clarifications or references, this comes across as FUD.
Documentation now is really good actually - some of the best in Open Source that I've seen lately (it was re-worked 2 weeks ago). Do you have specific examples of where it falls short for you?
I'd love to help, but your concerns are generalizations that aren't supported by references or concrete examples. Maybe you could represent specific things that your project needs that you've fail to accomplish thus far?
Apache Shiro continues to be the most flexible and easiest to understand security framework for Java and JVM languages there is - I doubt you'll find better.
But, above all, and I mean this with all sincerity, please don't write your own security framework unless you plan on putting a ridiculous amount of time into it. Nearly every company I've ever seen that tries to do this themselves fails miserably. It is really hard to get 'right' (and secure). Trust me - after writing one for 8 years, that's one thing I'm absolutely sure of :)
Anyway, feel free to join the Shiro user list and you're sure to find that the community is happy and willing to work through whatever issues you may have. You'll find that we take care of the people that ask questions and do our best to help out.
HTH!
My current projects use SpringSecurity and involve doing all three things you claim to be flaws in SpringSecurity:
The projects implement fine-grained access rules that go beyond simple ROLEs, and variously involve state of domain objects, extra request parameters, and so on. These are implemented using custom "access policy objects" that get called within my MVC controllers. However, access check failures are handed back to SpringSecurity by throwing the relevant exception. (These could have been implemented as standard SpringSecurity method-level interceptors, but the checks typically involve examining domain objects.)
The projects support both web and AJAX access, and deal with access failures differently for the two cases. This is done by writing some custom Authentication entrypoint components for SpringSecurity that choose between different authentication behaviors depending on the request URL, etc.
In other words, it can be done ...
Having said that, I agree with you on a couple of points:
It is not easy to wire this up kind of thing. I kept on running into roadblocks when using the <http> element and its associated configurer. Like ... you want it to use a different version of component X. But to do that you have to replace Y, Z, P and Q as well.
The documentation is really sparse, and not helpful if you are trying to do something out of the ordinary.
Andrey, I think this answer comes too late to be helpful to you; it is intended for those who land on this thread later and I hope it helps.
My company recently released as open source, OACC, an advanced Java Application Security Framework. OACC is designed for systems that require up to object-level security granularity.
OACC provides a high performance API that provides permission based authorization services. In a nutshell, OACC allows your application to enforce security by answering the question: Is entity ‘A’ allowed to perform action ‘p’ on entity ‘B’?
One of the key abstractions in OACC is a resource. A resource serves as the placeholder in OACC for the object in the application domain that needs to be secured. Both the actors (e.g. users, processes) and the objects being secured (e.g. documents, servers) are represented as resources in OACC. The application domain objects that are actors, or are secured, simply store the resource id to the associated resource.
The resource abstraction allows OACC, unlike other major security frameworks, to provide a rich API that manages permissions between resources. OACC persists security relationships in RDBMS tables (DB2, Oracle, MS-SQLServer and PostgreSQL are currently supported).
For more information please check out the project website: http://oaccframework.org
We use a layered security in one of our projects. The layers are the following:
HTTPS as protocol (Apache-AJCConnectors-TomcatServlets)
Only binary objects transferred between client and servlet
Individual elements in the passed objects (either way) are encrypted
Encryption key is dynamic, set up during initial handshaking, valid for 1 session
Conceptually, the security consists of the encryption key, encryption algorithm and the data on which it is applied. We make sure that more than 1 of the 3 is never passed simultaneously during a communication. Hope that helps. Regards, - M.S.

Implementation of Single Sign on in Rich Clients (not web)?

In our company, we have several rich Java applications that are used both by internal users and external users. We would like to begin migrating these systems to support a single sign on mechanism, and potentially allow our external clients to use their own authentication mechanisms to validate their users.
For instance, if we have a client who has a large number of users, and they would like to have their users only have to login using their company login information, we would like to support that behavior.
We have looked into using certificate based authentication systems (one of the common ones being Kerberos), and using that authentication mechanism to allow for external authentication services to be used in our system.
Is this doable? Are there specific implementation details we need to be aware of? I am not as concerned about specific technologies (although suggestions are certainly welcome), more about the core concepts and making sure we are doing the right thing wherever possible.
What about authorization - i.e. access to different services. Is there a standard or best practice to how this is handled when dealing with (potentially) disconnected authentication services?
As an additional note, our front end systems are made in Java, so specific information related to implementing this behavior in a Java framework is definitely appreciated (i.e. libraries that are useful, potential pitfalls specific to Java, etc).
Is it doable? Yes.
Are there specific implementation details we need to be aware of? Yes.
Each type of security implementation has its own implementation details that you're just going to have to figure out. Each one is different and has its own nuances.
You should be able to implement whatever type of security you chose. Kerberos is a fine choice. You might also look into Openid and CAS. There are many others though.
To handle the actual security itself you might consider looking into Spring Security. Spring Security is able to handle authentication/authorization fairly well. However, most of spring security is really focused towards security on the web and not client systems so you most likely will have to implement much of the authentication mechanisms yourself (using libraries available library whenever possible of course).
When designing your system, especially if you're going to have many different types of login types, try to build the login system as pluggable as you can. Which will take time and a lot of trial and error.
I would look into the Spring Security 3 book. It isn't a great book, but it does explain a lot about how to properly implement security. Leveraging springs work is highly recommend because trying to implement security all by yourself will be quite a daunting task.
Best of Luck.

Categories

Resources