i want to implement SSO in an application for that i have a SiteMinder policy server at the application which provide the login (say application 1) and also have installed the Siteminder webagent on the server of other application which am going to login through SSO (say application 2). This siteminder thing is already done by some other team. Now i want to get the siteminder session and from that session i want the HTTP_SM_USER this is all with the help of WebAgent. After getting the user i want to validate the user against the DB of 2nd application. Can anyone guide me how can i proceed with this work ?
The SM agent usually adds an HTTP header with the user ID to the incoming request. You can inspect this header in your code to determine the user. Note that this header does not come from the browser, the SM agent inserts it before the request is handed to your application.
Related
I have java web application using struts 1.x. Recently my application has gone through penetration testing and our testers found some security holes. Let me explain. In my application i have 2 users called ‘Admin’ and ‘user’. First our PenTester logged to my application as ‘Admin’ and they use ‘Burp tool’ to intercept the request and copy the whole request content into notepad and then forward the request. Now My application log in as ‘Admin’. They use another browser instance to login as “user” and use burp tool to intercept the request. This time they removed the whole request content and copy back the whole request content of ‘Admin’ and then forward the request. Now my application logged in as ‘Admin’ without asking any user id/password? How to restrict this situation? I already stored userid in my session variable after successful login of each user. The moment they intercept the request and copy the ‘admin’ request content, my session variable userid also changed to ‘admin’. How to validate this situation? Your help is really appreciated.
That is not really that much of an issue since the first part "copy the whole request content" is not easily doable if you have a proper HTTPS / SSL connection. That only works if the PC the user is logged in on as an admin is compromised in which case: nothing you can do about it anyway because they can just sniff the keystrokes and get the plain password.
If on the other hand you communicate without the S, namely just HTTP then the solution is: get a certificate and switch to HTTPS.
Apart from that your application can pin a session to an IP which means if the session id / cookie is stolen and someone else uses it you can detect an IP mismatch and ask for credentials again.
To prevent direct replay attacks like copying the request and sending it again you can introduce a hash that incorporates the timestamp or alternative measures, see. How do I prevent replay attacks? . The problem however is that copying the entire request means copying the cookies as well and if the "admin" cookie is copied this measure will not prevent you from "generating" a new hash based on the now admin user.
If BASIC authentication was not build to handle logging out, what alternate authentication methods exist for authenticating backend services that need to be able to log out?
I found these references stating that BASIC auth is not able to do log
out without some hackiness:
How to log out user from web site using BASIC authentication?
How do I log out?
We are using BASIC authentication to log into backend applications, and FORM authentication for frontend applications. After our team tested the stack on FireFox/IE, it was found that a user would not be able to log out if they logged into the backend services via BASIC authentication on those browsers. The hacks and workarounds are unacceptable to my team (asking user to enter incorrect credentials, making user close browser, use javascript to send incorrect credentials, ask user to clear browser cache, etc), so we are seeking advice on alternative authentication methods that DO allow logging out
EDIT- My temporary workaround for logout:
I am currently getting around this problem by using FORM authentication. One problem is that my backend services rely on the shared frontend login.html form, and another problem is that Postman does not support logging in via a redirected FORM input, and our client Arquillian calls blow up from the login form.
FORM authentication gets rid of the "I can't log out with BASIC" problem, but now I can't authenticate as straightforwardly.
Form based-authentication
If it's okay to keep the session state on the server, you can go for form-based authentication.
Send the credentials in the form, if the credentials are valid, the server will issue a cookie that will be sent back and forth to identify the session on the server. To logout, the session can be invalidated:
session.invalidate();
You also can configure your application to expire the sessions due to timeout:
<session-config>
<session-timeout>60</session-timeout> <!-- minutes -->
</session-config>
Token-based authentication
If you want a stateless mechanism, go for token-based authentication.
The client exchanges hard credentials (such as username and password) for a piece of data called token. For each request, instead of sending the hard credentials, the client will send the token to the server to perform authentication and then authorization.
For the token, you could use JSON Web Token (JWT). It's an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.
JWT is a generic name for the following types of token:
JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.
JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.
The image was extracted from this page.
The token can define an expiration date in the exp claim. For logout, you can remove the token from the client.
You also could keep the track of the tokens in a whitelist on server-side and invalidate them as you need. There's no need to store the whole token on server side though: Store only a token identifier in the whitelist and use the jti claim to store the token identifier in the token.
I suggest you to have a look at Apache Shiro, especially the way session are managed (https://shiro.apache.org/session-management.html).
They have namely abstracted the concept of session so that it can work in various situations: in a webapp (in such case, it's simply a wrapper around the HTTP session), in a standalone app, etc...
In your particular case, the front-end could open and close (logout from) a Shiro session that is shared with the backend layer.
See the sentence:
Heterogeneous Client Access
(...)
For example, a (desktop) application could ‘see’ and ‘share’ the same physical session. We are unaware of any framework other than Shiro that can support this
I want to create a Swing application client that connects to an EJB project which will have a login method to a secured client session.
When the client is run, you will provide a username and password, and thus login. However, if you type the incorrect password, you can be given n tries to provide the credentials.
I have configured Glassfish 4 to work with jdbc realm. Jave EE7 has a method to request user with the username and password, but I wanted have more control over the incorrect password and login.
Can someone please tell me how to do this ?
I tried using programmatic login but it does not seems to work.
You did not provide enough information. The answer depends on which HTTP client do you use and which authentication type is supported by the server.
If the server supports form based authentication after the login it will redirect to the requested page. Check that your HTTP client can follow HTTP redirects. Also, you need to understand where the session token is kept. If it is kept in cookies you need to store it in client and send manually with each request to the server.
I want to know how the token based authentication is done in Java. I want that if I hit my application then the system should redirect it to the login page and once the user enters the credentials, the user shall be validated and authenticated. Once authenticated a token should be generated which shall be handled across client and server. My concern is if the token is generated, how it is being passed to the client and how the client sends it back to the server on every request processing. I know that it has to be set in header. But my question is how exactly. I know we have spring and all but I want to know how it is being done using jsp and servlets.
I went across few websites but unfortunately could not find the expected result. A small demonstration shall be very helpful. Thanks in advance.
There is no such authentication token. There is a session token defined in J2EE Web Application server standard (https://docs.oracle.com/cd/E19644-01/817-5451/dwsessn.html). Once the JSessionId is established between server and client it is used to manage the user.
For example if you build you own authentication system you can bind the jsessionid with user login attempts, and keep a list of jsessionids which has logged in successfully. This is basically what authentication frameworks do.
Also, you can check this Under what conditions is a JSESSIONID created? and this: Spring security FAQ
I have a java servlet serving a website content and it is using forms authentication to login the users and let them access the content. Whenever the user access a protected resource he is redirected to a login form which is used to post the username/password to the j_security_check path in the web server. The rest is handled by the java security mechanisms which generate the user session, respond back and redirect him to the initial resource he tried to access. So far so good.
What I want to do, is provide access to the resources for non-logged in users in the following way: GET www.myserver.com/anotherLoginMethod=aasdfJKL where aasdfJK is a hash generated by the server. The server keeps an association of that has with a user account and when the user sends this GET request I need to:
1)Get the anotherLoginMethod parameter value.
2)Retrieve the associated user account ( credentials ).
3)Login the user automatically as if he was doing a POST with his username/password at j_security_check handler.
Is that possible ?
I tried using HttpServletRequest's login and authenticate methods in a Filter but with no success so far.
It is relatively simple. You need to decide
1. Where do you intend to keep the hash values and its association to the user?
2. How do you propose to give the hash to the user? Ensuring security is paramount for this step.
Once you have done this you can write a servlet filter which can intercept this request or you can have the logic in the servlet itself, get the user which is associated to the Hash value, generate a session as if the user has logged in successfully and redirect to the required URL. It is important to understand the security issues associated with such a methodology.