<vendor>
In the case of GemStone/J, the principal is associated with an X500 name.
The X500 name comes from the X509 certificate that the user used to
authenticate itself (login if you like).
</vendor>
> -----Original Message-----
> From: Jorgen Thelin [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, August 15, 1999 3:09 PM
> To: [EMAIL PROTECTED]
> Subject: Caller ID
>
> 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".
