Develop Reference

Avoid SPNEGO authentication for each request

I have a webserver which is using Jetty underneath along with SPNEGO authenticator and login service. I am using Firefox to connect to this webserver and can see that authentication is happening properly. But the issue is for each request from web client authentication is happening again and again, rather than only at first request. Does Jetty store any information to differentiate between an authenticated and unauthenticated user ? If not then can someone please help to recommend how I can achieve that? Also what it means to logout a user already authenticated using SPNEGO ?

The problem is not SPNEGO authentication but how you are managing session.
Once authenticated create a HTTP session and add the user's details to the session, and using a Filter check that there is a valid session is present if not do the authentication else skip the authentication.

SSO authentication with SAML2 in Java and How to Execute JavaScript by Using HtmlUnit

In one of my developments (using kerberos authentication to loginalong with HtmlUnit) its working fine in all cases , facing an issue after hitting SSO authenticated links where the SAML2 used.
I have searched all the way there is no proper explanation to get more info on SAML2 authentication for SSO secured pages.
I`m completely new for SSO authentication and SAML2 authentication,is there any separate API for this? help me to know on more on this.
Could you please help or suggest what is the best process to pass the user/password to get the authentication.
Thanks

Authentication itself is not part of SAMLv2 specification. SAMLv2 defines the exchange of information about authenticated subjects. Authentication happens at the SAMLv2 IdP. How this happens in detail is up to the IdP.
It could be that the following is possible in your case ...
Use HTTP POST to send credentials to the Login URL of the IdP. Capture the session cookie returned by the IdP. Send HTTP request to the endpoint of the IdP which allows so called IdP-initiated SSO and specify 'HTTP Redirect Binding' and the Meta Alias of the SP (this is the SSO-enabled app from SAML point of view). The IdP would return a 302 , follow the redirect, the SP should consume the SAML assertion included as a query parameter and you should be able to access the SSO-enabled app.
You may read SAMLv2 tech overview (http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html) to get some idea.

Get Active Directory credentials from http request

I have a Java+Spring application.
Assuming the browser settings are all correct and site is allowed, is it possible to retrieve logged in AD user credentials from an http request? Which fields are they? AUTH_USER? Are they coming with every request (GET, POST, PUT, DELETE etc).
I've successfully integrated AD authentication, with the user manually typing in their AD user and password. Now i am wondering, can login be done more automatically, retrieving credential from a browser's request?

I don't think this is possible. If you want an elegant solution instead of checking each user/password in your filter for example, have an eye to JWT. You could encapsulate your AD user in it and send the token to the client, itself sending back to you in a header.
The counterpart is that you have to integrate all the jwt part, as long as JWT is not native in Spring. I'm currently working on a personal project to integrate jwt and that's not so easy for someone starting with Spring Security.
This link seems ok for Spring

Secure Rest-Service before user authentification

I have a web application that provides several rest services (Jersey). Most of the endpoints are secured by BASIC authentification. Further more I use SSL for transport and demand POSTs for every call.
The clients/consumers are android apps.
So far so good. The only service that seems to be vulnerable is the registration. It's the 'first' service to call and a user does not exist yet. So I cannot use OAuth, etc. I also have to keep the endpoint easy accessible to enable the user to regster.
How do I secure this service, so it's not spammed by a bot flooding my database?

How about these?
Use a registration link with a token in the request parameter. Ensure that the tokens expire after sometime. You could create a token endpoint url as well for a client to get a valid token.
Use a custom header or a dynamic custom header in your request. Additionally, you could check for a dynamic custom header to validate the request's authenticity.
Use registration confirmation workflows, such as an email / text verification as soon the registration is done. Run a process every day to delete any user accounts, which are not validated in say x days.
I do not think you can really secure the registration URL in a HTTP way. IMHO, anyone who has the registration url can be a right guy trying to register. So if you ask me, option 3 is better than others.

Disable redirect to last accessed resource on form login Glassfish

I'm going to rewrite my previous question.
Glassfish redirects after form login to the last accessed resource, how do I go about to turn this off?
Our problem is that we get 415 in FF and IE because if I have a JSESSION cookie Glassfish will redirect to the last resource I tried to access but does not switch content type from (x-form-urlencoded).
Pseudo example (requests are the browsers' XMLHttpRequest):
GET /secure/resouce1 (json) -> Response "you're not logged in."
GET /login.xhtml
POST /j_secure (x-form-urlencoded) -> New location /secure/resource1 (x-form-urlencoded)
GET /secure/resource1 (x-form-urlencoded) <- HTTP ERROR 415 content type not JSON.

You will probably need to write a Filter to check for and catch that case. I like this tutorial (hoping the translation to English is understandable).

In my opinion it is better to use Basic or Digest authentication over SSL for RESTful services. Other options are including the credentials as part of the payload or creating a dedicated login service, which accepts credentials and returns a token. There are various reasons why form based authentication is less suitable for RESTful service: it requires a session, it does not use the existing HTTP Authorization and more.
If you need to call your RESTful service using AJAX then using a cookie for authentication can be a valid solution. They should only affect if the user can make a call, but not how the server responds.
If you would like to keep using form based authentication for your application I would suggest adding an additional JAAS authentication provider which will handle the RESTful services authentication. You can read more about it here.
Another option, which should be easier than JAAS, would be using Spring Security or Apache Shiro instead of the container based authentication.
Here is an example of configuring form based authentication with Spring Security. This post shows an example of how to secure RESTful services using Spring Security.

in your login page
reset the JSESSIONID cookie to prevent redirect last page
// login_form.jsp
Cookie jsess = new Cookie("JSESSIONID", null);
jsess.setMaxAge(0);
jsess.setPath(pageContext.getServletContext().getContextPath());
response.addCookie(jsess);