I've been looking at several frameworks that handle authentication and authorization (Apache Shiro, Spring Security, JAAS, Apache Wicket) and am wondering about the disadvantages of JAAS.
I've been reading that it is more complicated and only provides basic security, but I don't quite understand what that means. Also, I've heard to not use it if the application needs to be ported to another system - why is that?
'It provides only basic security' is nonsense. JAAS is a framework within which you can write whatever you need, so it therefore can provide whatever you want it to provide, from simple authentication to any level of role-based authorization, in association with Container Managed Authentication, which IMHO is the only sane way to manage web-app security.
The JAAS programming model I find a little odd, kind of inside-out, but you can do very powerful things with it: for example I built a webapp that would accept a login via either form, session ticket, expiring auto-login token (e.g. for password reset), or client SSL certificate, and in fact it is ideal for scenarios like this.
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I am evaluating security for my web application. As I am using Spring in my web application I would like to leverage the Spring Security framework. I searched for more info about web security and come across OWASP community and it's top 10 attacks list. So my question is; would it be suffice to configure Spring Security to secure my application? What all security threats out of OWASP top 10 (2013) are handled by Spring Security Framework?
Building secure applications is a challenging task and there is no "silver bullet" product which would make the application automatically secure for you. Therefore the simple usage of Spring Security certainly does not automatically mean that your application is secure! Spring Security is a great tool which helps with many aspects of building of secure applications, but like with any tool you need to know how to use it properly.
Spring Security can help you address at least the following OWASP TOP10 issues:
A2-Broken Authentication and Session Management - by providing mechanisms for efficient and secure authentication and session management
A4-Insecure Direct Object References - by providing mechanisms for authorization within application
A6-Sensitive Data Exposure - Spring Security's crypto module provides necessary cryptography capabilities
A7-Missing Function Level Access Control - by providing means for authorization in UI and server side
A8-Cross-Site Request Forgery (CSRF) - by providing support for generation and validation of tokens mitigating CSRF attacks
I advise to use a layered security architecture. I mean, it’s possible to create a secure application by hand but it’s extremely difficult to implement. Some security features such
as authentication and basic access control (url level or GUI component level) are relatively easy to implement but requirements such as instance level security (specially working with legacy databases), Sql Injection and XSS are harder.
I recommend to use Spring Security and implementing as much as possible custom validations. In addition to that I recommend to use HDIV in order to add an extra security layer that could
help to avoid the exploitation of risks not covered by custom validations. Specifically the features offered by HDIV are:
A1- Injection: regarding HTTP parameters’ values and urls HDIV reduce the risk of this vulnerability to only the data that come from text fields within forms, applying integrity validations (assures the received value is the same as the generated at server side) for the rest of the data that come from client side. For text fields included within forms, HDIV offers generic validations (whitelist and blacklist) in order to avoid injection attacks injection attacks.
A2-Broken Authentication and Session Management: HDIV doesn’t offer functionalities for
this web risk.
A3-XSS: the same as A1 but in that case to avoid XSS risks.
A4-Insecure Direct Object References: HDIV controls all the data
generated at server side ensuring the integrity of the data and
avoiding this vulnerability.
A5-Security misconfiguration: HDIV doesn’t include specific functionalities for that but doesn’t allow the access to resources not sent by the server previously, avoiding the exploitation of unexpected behaviors or access to private resources.
A6-Sensitive Data Exposure: HDIV offers confidentiality feature to
hide the values of HTTP parameters.
A7-Missing Function Level Access Control : thanks to the integrity validations implemented
by HDIV, avoids the exploitation of this vulnerability and limit the user to execute legal actions and maintaining the original contract (GUI or API) offered by the
application.
A8-Cross-Site Request Forgery (CSRF): HDIV adds aleatory tokens to
avoid this vulnerability
A9-Using components with known vulnerabilities: HDIV doesn’t include
specific functionalities for that but thanks to the interaction
limitations applied to the user in many cases is not possible to
exploit the vulnerability.
A10-Unvalidated redirects and forwards: This vulnerability is
mainly related to the manipulation of non editable data or data
generated previously at server side. HDIV controls all the data
sent by the server and doesn't allow the redirection to malicious
web sites.
In addition to these functionalities to protect from OWASP top ten web risks, HDIV generates also logs related to the malicious activity or attacks against your web site including all the information about the attack and the username within authenticated web sites.
Regards,
Roberto Velasco (HDIV team)
You can try HDIV which has support for multiple frameworks.
I am building an ASP.net MVC web application and I am starting to look into security.
What would be the best way to identify the user on subsequent requests (after they have logged in). I'm thinking of some form of authentication token or maybe using a cookie?
Ive read about Forms-Based Authentication but I'm not sure what would be a good approach?
This is a very broad question and there are many ways to answer it. I would recommend that you learn the basics of identity and access in ASP.NET by reading each topic in the ASP.NET Identity section and understanding what options you have. At a basic level, you need a mechanism to register users in a repository/database of some sort, validate their credentials when they log in, and a way to persist their user session in a browser (such as via a cookie). All of this is discussed in that section with examples.
The good news is that there are many valid authentication options that are pretty easy to implement and don't require you to be an expert on security. You can create/maintain your own member database, use Windows authentication, outsource authentication entirely to external identity providers such as Facebook/Google/Azure Active Directory/etc, and so on. The new tooling in Visual Studio 2013 also makes this much easier for you to manage. I would highly recommend you familiarize yourself with all of these options before jumping in and writing any code.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I'm currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).