Jorgen,
<vendor>
Bundled with the Secant Extreme Enterprise Server for EJB (EES/EJB) is an
implementation of the OMG Security Service. As a result, with our product
you have available the Level 2 interfaces defined by the OMG standard which
define the objects and the methods you may use to authenticate yourself in
the domain. We have also provided as part of the EES/EJB product, the
standard EJB/Java security interfaces, which may be used as well.
</vendor>
Hope that helps.
DaveTillman
Secant Technologies
www.secant.com
----- Original Message -----
From: Chris Raber <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 17, 1999 9:36 PM
Subject: Re: Caller ID
> <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".
>
>
===========================================================================
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".
