We Keep Coding

Concept behind how java clients authenticate with JEE server like weblogic, jboss etc

I have been going through lot of documentation to understand what is the standard way (if there is any) in which the java client authenticates themselves with the applications deployed on server container like weblogic, jboss etc.
After reading about JAAS & JNDI authentication documentation for weblogic, I am able to understand the flow, but no documentation answers the below queries
Are JAAS and JNDI the only available methods for authenticating java clients ?
What I understood so far is, that each application server can provide its own abstraction layer to perform authentication, for example OPSS in weblogic, but eventually they all depend on native authentication methods available in JEE framework. Please point out if this assumption is not correct.
The confusion is greatly amplified as some article mention that JAAS security doesn't exists in JEE. Is that valid for java 7+ too?
The oracle weblogic documentation I have been going through clearly states JNDI & JAAS as the standard authentication approaches, and even goes to the extent to specifying JAAS as being preferred over JNDI authentication.
https://docs.oracle.com/cd/E28280_01/web.1111/e13711/fat_client.htm#SCPRG225/

Here is clarification I got based on the material read during last two days.
Most basic thing - All application servers provided provide an identity store, that can store users & groups. Applications can refer to this identity store, as when it is deployed on the server.
A Caller or User is an individual named identity defined in an identity store.
https://dzone.com/refcardz/getting-started-java-ee?chapter=1
How the applications execute authentication?
Based on pure JEE framework, the authentication methods can be classified based on the type of application it secures:
Web Application Authentication
Declarative:
We use either deployment descriptors or #annotations to specify these authentication enablers:
a. Which options to use for rendering authentication i.e. basic (browser popup), custom form, SSL, etc.
b. Which resources(URL patterns) need authentication and authorization.
c. Which users or roles (via groups) are permitted authentication or authorization.
Programmatic
Here we make use of security methods() in built in interface HttpServletRequest.
The application(e.g. servlet) call following methods to instigate authentication from within an "unconstrained" resource.
a. request. Authenticate: A login box pops up to collect credentials.
b. request. login: This methods takes login/password without the pop
c. request. logout: Resets the user/caller identity
There are several other methods also available, that provides more details of the authenticated user like isUserInRole(whether it's in given role), GetRemoteUser(gives user name), etc.
EJB Authentication
How EJBs are authenticated??
EJBs are can also be secured in the same way, as web based apps. i.e. Either with Declarative or programmatic security. Some caveats to this statement, but those are not relevant to current discussion.
So why do we need JAAS, and what is JAAS?
To appreciate this, let's understand a practical scenario for any:
An application may have multiple authentication requirements e.g. password, certificate, authentication users from multiple security realms, perimeter authentication, etc. Do we have to code so much for every application, and type of authentication? Now, it can be cumbersome and complex create & maintain code for authenticating users based on these different techno-business requirements.
To address above situation, there has to be a Pluggable way to writing code for authentication, wherein, developers would only be responsible for mentioning(not coding) which AuthenticationProvider has to be used, and writing code to call the loginModule of that particular provider, which eventually has code to authenticate the given user/caller.
This framework of providing pluggable authentication is called Pluggable Authentication Module in LDAP world.
"JAAS" is java implementation of PAM framework. With JAAS, either updated, or additional authentication technologies can be plugged under an application, without modifying the application code as such.
After Authentication, JAAS also enforces authorization.
JEE provides libraries to implement JAAS in applications!
Is JAAS implemented in same way across different enterprise application servers like Weblogic, JBoss, etc.
Well, "It can be", "but is usually not" implemented in same way across different application servers.
This is because application server may provide its own libraries, which can be used to implement JAAS.
Hope this clarifies the JEE security model to folks who do not have development background.

Single Sign On Framework

I want to implement a SSO Framework. My requirement is thus:
Once a user log's into particular website and he clicks on an external link, he should not be asked to verify his credentials again.
EDIT: Here, I have control over the 'external link' that I speak of. The first link that the person sign's into can provide me credentials or other information that I require, but I have no control over it.
I researched a bit, and found CAS to be relevant for my requirement. But, I don't want the end user to login to CAS initially, I need a framework that receives the credentials from the currently logged in website and uses the same to login to the other external site. Security is, of course, an important factor. Can you please give me some pointers/ ideas as to how to go about designing such a framework?

Based on what you're describing, it sounds like an Identity Provider (IdP) initiated SAML profile would meet your requirements (a good visual representation of this is here). The original web site your user is logged in to will function as the Identity Provider. Once a user is authenticated with that application, they will then be able to access your external application by clicking a link. Instead of being directed to a log in page for your application, the original app will instead forward the user's authorization details via SAML to you where the signature will be verified and possibly checked with the identity provider. If everything checks out, the user will be redirected to the requested resource from your app without having to sign in.
Note, that the above describes the protocol of the SSO. There are many different frameworks that support SAML that you can use. Two that you can research are Shibboleth and, as already mentioned, OpenAM.
This is a rather simplified explanation based on limited details, but hopefully it will help lead you towards a solution. I would recommend doing a good bit of research on the protocols and frameworks available before making your decision. Also, a proof of concept never hurts to prove out the solution will work for you before investing in it to a point of no return.
Good luck.

OpenAM should help you:
OpenAM provides open source Authentication, Authorization, Entitlement
and Federation software. Through OpenAM, the community actively
continues development of OpenSSO.
OpenAM provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security
component in a network infrastructure. OpenAM provides the
foundation for integrating diverse web applications that might
typically operate against a disparate set of identity repositories and
are hosted on a variety of platforms such as web and application
servers.

On the wikipedia page List of single sign-on implementations you can find a list of SSO implementations, there is a column indicating the licence.
Read about jboss sso from here.

Securing REST API in JBoss

I'm developing a RESTeasy JSON API under JBoss-As 7.
I have another separate web-server.
I am developing with JAVA on server-side, and on client-side with Javacript, JQuery, AJAX.
So, I have 2 distinct *war*s, let say they can be accessed as following:
https.//localhost:8443/services
http.//localhost:8080/web
Now I want to secure these two guys; RESTeasy API and web-server.
Let me tell about my structure:
I keep the users in DB with username-password. These are the only users for now.
I have a login page to authenticate my users (I don't want http basic auth popup and any workaround about that)
The clients of REST API are browsers (not web server). The static page is load, and then some other dynamic things are load through REST API, calling within from browser using JQuery, AJAX, whatever.
All communication can be through SSL/TLS, no problem.
For the future, scalability (clients other than web-browsers, ability to authenticate with social network logins, etc.) should be in mind.
My scenario is as following:
Client is browser.
Client wants to access a web page web/aaa.html which is restricted to authenticated users.
Client is redirected to login page: web/login.html
Client filled the FORM and sent to ... either,
a) to the rest-api, or
b) to web-server,
not sure (So, here you have an implicit question).
But in any case, what a or b should do is the same:
Check username-password. Let say they are checked and the user is authenticated.
From now on, I should have got these two things at the same time:
1- Client is authorized to navigate the restricted pages.
2- Client will be authorized on REST API calls.
So, I need these 2 things at the same time happen, after authenticating in login page.
I have read lots of things, about authorization in REST API, with tokens, keys, etc. and yes I also have heard about Spring Security, Apache Shiro, etc.
And yes, I do not want to implement a new security framework by own and I will use one. I imagine that some framework can produce/check tokens etc. for me.
Before Spring Security and Apache Shiro, I want to know about resteasy skeleton key JBoss module.
There are these sources:
https://github.com/resteasy/Resteasy/tree/3.0.1.Final/jaxrs/examples/oauth2-as7-example
http://docs.jboss.org/resteasy/docs/3.0-beta-2/userguide/html/oauth2.html
But, they didn't seem to me very explicative, and also I am not sure if they are what I need.
Is there someone who knows how to configure skeleton key (or in general JBoss App layer) and give me useful example to achieve what I've described, please?
Or, could you give me some other advice/example to achieve my goal, especially noting that my question is about "how to implement"? I don't see where to begin.
Thanks in advance.

For securing REST Services, We can use following framework
OAuth (Open source - RFC6749)
Apigee

SSO via encrypted token

We have the need in a project to implement single sign-on for two different web applications, one being our own and one is implemented by someone else. For our own application we have user/password stored (encrypted) in the database. Since our application will be integrated in their environment, we now need a mechanism to let us authorize the user already being logged in at their side without showing a login screen again.
Since I'm not a security expert myself, I started reading (on a high-level) about a few techniques regarding SSO, e.g. OpenID, Kerberos, SAML, CAS - but I have not yet gained practical experience.
Before marching in the wrong direction - can someone provide me with own experience in that field and point me to a framework to use or a good (and recent) article about how this should be done?
One more infomation: The customer talks about preferring to pass encrypted tokens between the two webapps. Does this make sense? And does this lead to a certain technique?

We use a SAML realization for this purpose ( https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/index.html ) - it was easily integrated inside our existing web applications.
The working scheme can look like as follows: you will have a login page, where the SAML framework redirects user. so, after successful login, he got a cookie with the auth token, and redirected back to the web application page. you will also have an identification webservice, which you can call, passing the token provided, and be able to get the auth credentials (user role, etc) from there, so all your web applications can identify this user as logged in.

Username in HTTP Header for SSO

I am looking to add single sign on (SSO) to one of my web applications. I don't want anything heavy at the moment, I just want to know the userId of the logged in user, without the need for them to enter a username.
The web app is an internal application, so I can guarantee they are coming from a Windows PC etc.
I have looked at jCIFS, but this doesn't seem to be supported any more, and recommends a commercial product.
I have also looked at WAFFLE, but I am building SSO for a playframework application, which does not use a Servlet stack, so I can't make use of the SecurityFilter. I have tried to make sense of the WindowsLoginModule, but couldn't really understand what I had to do to implement it.
Is it possible to just get the username from the HTTP header, or does it require some negotiation first before it will post the header?

You want the windows user to automagically login to your intranet webapp. So the user accounts would sit in an active directory and the usual microsoft way would be to use a protocol like NTML oder Kerberos. Applications are generally advised not to use NTLM, although there are enterprises still using NTML (and jCIFS) for SSO.
A quick search on Kerberos and Java showed this article. It seems to depend on the Java EE stack (JAAS).
For a more stripped down approach: Usually, you cannot sent the username in a http request in a portable way. With ActivX you could do:
var wshshell=new ActiveXObject("wscript.shell");
var username=wshshell.ExpandEnvironmentStrings("%username%");
On the server side, you can parse the http header and extract the username with your technology of choice.
Well, security doesn't matter in your playframework application?
Why don't you use long-living cookies?
Hope it helps!

In an intranet context with ActiveDirectory and workstations registered in the domain, the HTTP SPNEGO Negotiation support is the best option. But it requires specific skills around ActiveDirectory and Java Kerberos implementation.
Spring Security provides implementation and documentation to set it up. But Secure.Security is not designed to support token-based authentication like HTTP Negotiation. So using Spring Security will require a specific integration module.
Other options are OpenID and shibboleth but both requires a dedicated server, which can be configured to do SPNEGO itself. Thanks to available Play modules, integration in your application will be easier.
The only way to get the username in an HTTP header without client-side complex and unsecure/unreliable tweaks is to use an authentication proxy between browsers and your application server. Most of these proxies also support Kerberos SPNEGO as authentication mean.

Non-heavy answer
It sounds like it should be possible to get your ops team to implement a Group Policy which will send the logged-in username down the wire as an HTTP Header.
Otherwise, you're correct in your assumption that there is some sort of negotiation "dance" between IE and your server. See here. Perhaps you can fake this dance in your Play code.
Heavy answer
I know jCIFS and this example uses servlets and filters, but the important bits of code can be extracted and a custom Play Authenticator can be built (I can paste a Scala example override of play.api.mvc.Security.Authenticated , but your answer is tagged Java). You only need the request headers (not body) so it should be doable in an authenticator.
PS jCIFS seems to have had an update since your post, so I'm presuming you'd reconsider using hacking it. I'm wary of unmaintained libraries too, but sometimes they just reach a maturity and stability which alleviates the need for any more updates.

Active Directory uses Kerberos, so all logged in users should have a kerberos ticket.
A fast google found this:
https://blogs.oracle.com/wyllys/entry/kerberos_web_authentiation_with_apache
If you want the windows logon details, I think it's your only option.

You can try to use Shiro for enabling SSO in your application.
Shiro id independent of the servlets and since your framework does not support Servlets you can very easily go for Shiro.
You can create a Realm where you define the hashPassword.
You can configure the username and the hashPassword and ask the shiro to authenticate your user with the hashPassword.
You will then assign role for the user which will serve your purpose of SSO.
You can authenticate user for more than one application and hence when user logs into another application the shiro has already authenticated you and hence it will straight away log you inside the application..
You can go through the shiro documentation(exhaustive and you should be able to configure it on first go) from the following link:-
http://shiro.apache.org/
It provides you many out of the box functionality for authenticating and authorization along with security and Cryptography modules.

The username isn't sent in the header. Even if it was this shouldn't be relied upon as a savvy user could fake the values.

If NTLM would be a valid option for you Jespa might be a good alternative to JCIFS. Jespa (unlike JCIFS) supports NTLM v2, among other things. The limited version of it (up to 25 users) is free.

You can always get any header from filter. See javadoc for HttpServletRequest.