Using JAAS in the app server context usually involves 3 different things:
1) Configuring the required JAAS login module(s) with the application server.
2) Associating the JAAS configuration with the EJB components
3) Using the proper JAAS configuration on the client application side (servlet or standalone application).
None of those 3 steps are standardized by JAAS or J2EE. It means that it will all be proprietary to the application server you are running on.
But none of these steps require modification to your EJB code. It is "only" application server specific configuration + deployment descriptor (unless you want to write your own JAAS module and then this is a different story).
In a session bean, you can access the EJBContext and then the current principal. So getting the user name is not a problem in such context. I think that similar mechanism exists in a servlet container.
Thank you very much for a clear and concise answer!
I guess it's time to RTFM and see if I can make JAAS work, that will save me a lot of coding.
If it comes down to it; Does building user management, session management, permissions, etc. into your application violate any J2EE priciples or standards? I've not read of any standards, but JAAS is there for a reason I suppose.
I do not think you are violating any J2EE standards if you are implementing all that on your own.
It is the same thing as saying that you are using something like Hibernate to manage persistence instead of entity beans. Your are not violating the J2EE principles when doing that, you are just not leveraging everything that the app server can offer (and may be for good reasons).
In the domain of security, I think it is a tricky decision to do everything on your own. Each app servers come with a set of JAAS login modules (for databases, LDAP, Kerberos, etc...) and saying that you are going to do all that on your own is not that simple (but may be you do not care and you application needs to work with only one specific domain).
Another point is the integration with the app server. For example, in WebLogic, the administration console allows you to create users, assign roles and permissions to users, etc... Do you want to just forget about all that? May be you do or may be your "customers" will not like that and are going to ask for a tighter integration with the application server.
It violates the aspectization of the security out of the business tier, but if the role based j2ee security model does not work for you, it does not work. Unfortunately there are no consistent integration points that allow for portable security into both the ejb and web tier. Servlets have filters which come close, but depending on how deeply you need to interact with the authentication decisions you may need to drop down to a tomcat valve to achieve this. There is no equivalent of the servlet filter in the ejb layer. JBoss has a custom interceptor as do other servers.
The aop framework in jboss 4.0 allows for a more uniform aspectization of the application, but its also not a standard.