I am designing an application that will require users to first login and then access several secure web pages. I plan on using AWS along with the AWS Load Balancer and expect several AWS instances of this application to be running. What is the "best practice" for persisting security credentials across several web pages and several instances? The user will login and then navigate through several secure web pages. I presume the AWS Load Balancer will be round-robin redirecting each https request to a different server instance. How does each instance know that the user has successfully logged in? Also, how do I keep the secure pages secure from external access? The platform will be Linux, Java, and Spring-boot.
I presume the AWS Load Balancer will be round-robin redirecting each
https request to a different server instance.
That's the default ELB behavior, but you can enable sticky sessions on the Elastic Load Balancer to lock a user to a specific back-end server, at which point the HTTP session stored on that one server keeps track of the user's authentication state.
How does each instance know that the user has successfully logged in?
They don't, unless you configure a shared session store of some kind. I prefer using Redis (ElastiCache) as a shared session store. Of course if you enable sticky sessions at the ELB that might prevent the need for a shared session store.
Also, how do I keep the secure pages secure from external access? The
platform will be Linux, Java, and Spring-boot.
That's not really a feature of AWS. You would need to add security to your application. Look into Spring Security.
Related
I have a question about integrating authentication into my web application.
First let me give the relevant technology background of my web application -
Application/Web Server - Tomcat 8.5
Underlying OS - CentOS 7.x 64-bit
Programming technology - Java Servlets 3.1
JDK version - 1.8
UI technology - Browser based; Developed using Angular2/Javascript/HTML/CSS
Web application users - Targeted at enterprise users
As of now, there isn't an authentication system built into the web application. However as I build this web application, I need to include an authentication module.
My main points to consider as I decide on authentication system/technology are -
I preferably do not want my application to deal with the storage and protection (on disk) of the user credentials
I preferably do not want my application to deal with enforcing password complexity, history, expiration policies etc.
My application will have to provide for -
A login page to allow the user to login
A change password page
A create user page
Based on the above, I am currently thinking of deploying a Windows Server 2016 instance as the Active Directory(AD) server that will hold the credentials for the application users. Note that at this point, this Windows server is not planned to be shared with any other application to support a single sign-on experience across applications.
I am planning to configure my Tomcat server with a JNDI realm to authenticate users (against the AD) and then use some kind of Java AD library that will allow me to create an user and change a user's password in AD via my application's create user and change password page.
My application will support its own custom roles and authorization constraints so i am not looking to use AD's group membership for authorization within the web application.
My questions are -
With the above setup, are there any reference authentication systems/libraries/modules that might be better suited (than AD) to integrate within my web application?
If I go with the above Windows AD server approach then are there any Java (inbuilt or community developed) AD libraries that allow for creating an user in AD, changing user password in AD etc. I have used the JNDI realm before so I am sure that it can be used to authenticate the incoming user against AD
I am not an expert in Spring Security and my web application does not currently use Spring Security but I am open to using it if Spring Security includes a solution to my problem described above.
I am also not worried about supporting single sign-on as such and its totally fine in my scenario if the application users have a separate login for my application.
Since my web application is targeted at enterprise users, I don't want to leverage Facebook authentication. As much as possible I want to ensure that the credentials are maintained in a server within the deployment infrastructure rather than the credentials being hosted and maintained by a 3rd party service
Thank you for your help and suggestions
Suppose I have more than one web application servers running and I am logging in a User from Server1 thus his session starts.As http is stateless, suppose if the next request goes to Server3 than the Sever1 which was used to login to the application,if I use cookies, hidden form , its not going to work in Server2.
So how do I manage the session ?, maybe by generating an ID (or even reusing the jsessioid generated ) and storing it in a central database,so that all servers can access this session ID and validate it before processing the request.Then in that case, I need to develop a mechanism to store all the session data as object to the database.
Is there any other built in mechanisms available ?
If you are deploying application on more than one server, you should use "Clustering". Application servers are able to handle this scenario using "session replication". With session replication, each server will have a copy of the active users session. IF the first request goes to server A and second request goes to server B, it will be transparent to application code and end user.
For clustering/session replication in Tomcat, you can have a look at this link.
Spring provides the session management:
Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution. It also provides transparent integration with:
HttpSession - allows replacing the HttpSession in an application container (i.e. Tomcat) neutral way, with support for providing session IDs in headers to work with RESTful APIs
WebSocket - provides the ability to keep the HttpSession alive when receiving WebSocket messages
WebSession - allows replacing the Spring WebFlux’s WebSession in an application container neutral way
Source: Spring docs.
Please check this for further information: https://spring.io/projects/spring-session#overview
If your infrastructure ( Server 1, 2...) are connected to a single network appliance like Citrix Netscalar, then you can use IP or Cookie Persistence so that netscalar sends further requests to the same server.
With AppScale with is there a facility with AppScale to "secure" an application deployed with it, that is for instance an application can only be accessed through some sort of secure connection?
So we won't have to put too much security logic (like Spring security) on the application, especially to those apps that the sole purpose is to provide Restful key-value access to the datastore like this: http://bit.ly/RvLUTw and http://bit.ly/PTZkW. And the purpose is not really a web application but a "datastore appliance."
Sure, since AppScale just runs Google App Engine apps, anything that you do for an App Engine app works when running on AppScale. If by "secure connection" you mean HTTPS, then you could take your app.yaml file and add secure:always on each route to force HTTPS. Here's an example:
handlers:
- url: /youraccount/.*
script: accounts.py
login: required
secure: always
If by "secure connection" you mean authenticated access, you can use the Users API to restrict access to logged in users or users on a white-list. If you need it to be programmatically accessed, you can log in to the AppLoadBalancer via your script (as it has a RESTful interface), save the cookie it gives you, and then use that when you make requests to your app.
I have two different web applications running on two different instances of tomcat. I need to be having a common page with links to both the applications. But I should be able to log in only once and should be able to access links in the other application without being asked to login again.
Is there a way to do it ?
Check out josso which you can use to create a single sign on solution across your applications
You can use a token parameter, where the token could be the username/some credentials encrypted. You can verify the credentials are correct in the 2 apps.
An alternative, if your applications are under the same domain would be set cookies and recreate the session from them.
Thanks for the replies. We finally decided to use Pre authentication Filter provided by Spring security to fulfill this requirement along with authentication token for validation
The easiest way is to provide Central Authentication Service (CAS) : Single Sign On. It provides centralized access control and authentication for your applications. And Spring Security has a CAS module that integrates with CAS seamlessly. For that you need to setup a CAS server.
More Info on how CAS works and implementation see the documentation.
Spring-Security Documentation
CAS architecture
Another way of doing is to create a Tomcat cluster and maintain the session replication between the 2 nodes under the cluster.
Please refer the Tomcat manual how to create the Tomcat cluster and enable the session replication.
You can use Spring RMI to update the each other nodes App context about the session info etc...
We are looking at building an application that either proxies a standalone LDAP server or delegates to an embedded Java LDAP instance (ie: ApacheDS, OpenDS) in order to log requests and determine who is accessing which applications on our very large corporate network.
My question is is there a good way to intercept an LDAP request and "pull it apart" or have either OpenDS/ApacheDS push notifications of requests coming into LDAP.
You don't need to do any of that. You can configure LDAP servers to log accesses, either in the LDAP directory itself or elsewhere.
OpenDJ (the actively developed fork of OpenDS, http://opendj.forgerock.org) has support for multiple and customized access logs, so you can even configure some filters for the specific requests you're interested in.