Client authentication to the EJB server is done when the JNDI InitialContext is
created to lookup
the EJB objects. User ID and credential are specified as context properties as
shown below:
Hashtable pros = new Hashtable();
pros.put(Context.INITIAL_CONTEXT_FACTORY,
"package.name.InitialContextFactory");
pros.put(Context.PROVIDER_URL, serverHostUrl);
pros.put(Context.SECURITY_PRINCIPAL, user);
pros.put(Context.SECURITY_CREDENTIALS, password);
InitialContext context = new InitialContext(pros);
Different authentication schemes may be provided by vendor-specific EJB servers
to support
SSL, two-way authentication, or others.
-JL
>From the EJB architecture and specifications, it is clear that the
identity of the caller of an EJB is highly significant (as it forms the
whole basis of the EJB access control system), but I have not seen any
details of how this is actually achieved in practice.
Please note that I am *NOT* asking HOW the client identity is sent from
the client to EJB server (i.e. propagation of the client context), but
rather *WHAT* is actually sent (i.e. the process for authenticating the
client in the first place).
Nor am I talking about the concept of "principal delegation" for calls
from one enterprise bean to another, which is another topic entirely!
Clearly some sort of java.security.Principal object will be sent or made
available to the server (as the spec in particular says
getCallerPrincipal() cannot return a null value), but I am hoping
someone can shed light on the mechanism by which this caller identity
object is created / initialised.
The caller identity mechanism seems to me to imply some sort of "logon"
operation to the EJB server, but none of the code samples / tutorials /
books I have seen appear to do anything like that, so I am still
slightly puzzled about how this is actually achieved in practice.
Perhaps someone could comment on how this area is handled in real world
EJB server products.
Also, any details of products that support multiple / "pluggable" client
authentication mechanisms would be useful - the example quoted in the
EJB spec of using different authentication schemes depending on whether
a user is assessing through a company's own Intranet or externally
through the Internet (but still yielding the same security Principal) is
a highly desirable setup in practice for most enterprise applications.
Until the JAAS (Java Authentication and Authorization Service) API's are
available, I assume that the authentication mechanism will be server
specific - this seems to be confirmed by my reading of the EJB spec
document, but as I cannot find any coding examples of this feature I am
still purely guessing here!
Could someone supply a snippet of skeleton code doing client
authentication with a specific server, or point me to a suitable source
of a real example?
Also, please feel free to correct me if I have mis-interpreted the
intentions or requirements of the specs here.
Thanks,
- njt
------------------------------------------------------------
| Software Technologies ----:---- http://www.SwTech.com/ |
| -----------> One-stop Developer Reference <----------- |
| Technical reference for professional software developers |
------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
