The EJB interoperability protocol is based on IIOP (GIOP 1.2) and the CSIv2 CORBA Secure Interoperability specification.
CSIv2 :
http://www.omg.org/technology/documents/corba_spec_catalog.htm#CSIv2
The Security Attribute Service (SAS) protocol defined by the spec was designed under the following assumptions (there is list of assumptions), but the one relevant to this thread is :
1. Secure interoperability is predicated on the use of a common transport-layer security mechanism, such as that provided by SSL/TLS.
2. The transport layer provides message protection as necessary to protect GIOP input and output request arguments.
3. The transport layer provides target-to-client authentication as necessary to identify the target for the purpose of ensuring that the target is the intended target.
The Username Password authentication also called GSSUP mechanism assumes that transport layer security, such as that provided by SSL/TLS, will be used to achieve confidentiality and trust in server, such that the contents of the initial context token do not have to be protected against exposures that occur as the result of networking.
The SAS protocol supports the establishment of both transient and reusable security contexts. Transient contexts, also known as stateless contexts, exist only for the duration of the GIOP request that was used to establish the context. Reusable contexts, also known as stateful contexts, endure until they are discarded, and can be referenced for use with subsequent requests. The SAS protocol includes a simple negotiation protocol that defines a least-common-denominator form of interoperability between implementations that support only transient contexts and those that support both transient and reusable forms.
Qutoing from the EJB Spec :
---------------
The secure interoperability requirements for EJB 2.0 (and later) and other J2EE 1.3 (and later) contain- ers are based on Conformance Level 0 of the Common Secure Interoperability version 2 (CSIv2) Final Available specification [ 23 ], which was developed by the OMG. EJB, web, and application client con- tainers must support all requirements of Conformance Level 0 of the CSIv2 specification.
-------------
Conformance Level 0 of CSIv2 spec requires support for Transient Security Context's and does not require support for stateful security contexts.
Thanks.
On 11-Jul-2011, at 4:06 AM, forums_at_java.net wrote:
> I noticed that once an EJB (tried Stateless and Stateful) requires
> authentication (by specifying a valid <as-context> in
> glassfish-ejb-jar.xml), Glassfish keeps calling the authenticateUser()
> method of AppservPasswordLoginModule for every single call to one of the EJB
> methods. Which doesn't seem correct to me. Since I couldn't find any
> documentation whether this behaviour is correct or not my question is: is
> this normal behaviour, a bug or am I just doing something in the worng way.
>
> I'm calling the EJB method from a Java client through the remote interface
> using jndi. I tested this behaviour by writing a custom login module (by
> extending AppservPasswordLoginModule) and verified this behaviour by using
> the FileLoginModule (to make sure I didn't make a mistake in my custom
> implementation of AppservPasswordLoginModule).
>
> I do understand that the authenticateUser() needs to be called once to
> perform authentication, but didn't expect that authenticateUser() would be
> called for every next request as well. The behaviour is expensive in terms of
> performance (you might need to lookup your credentials in a database to
> verify) and makes your security also sensitive to replay attacks (sending out
> the exact same credentials over and over again over the wire makes things
> easier for the man-in the middle waiting for a replay attack).
>
> So my question is: is this normal behaviour? In other words; Doesn't
> Glassfish create a client-server session in which it saves the logged-in
> state of the client to avoid subsequent calls to authenticateUser() of
> AppservPasswordLoginModule?
>
> Thanks in advance for your help,
>
> Jan Snelders
>
>
>
> --
>
> [Message sent by forum member 'snelders']
>
> View Post: http://forums.java.net/node/820784
>
>