Hi.
Thanks for the response.
I might be way of, but would getCallerPrincipal() yield the expected result
in a case like this:
1. 'User1' enters the system.
2. 'User1' is mapped to the role basic-user using some lookup (LDAP,
Database).
3. A JavaBean carries out the stuff 'User1' need to do by connection as
'basic-user' to an EJB in the EJB-tier.
4. The stuff that can be done in the EJB-tier is related to the role
'basic-user'.
5. At any time during the work in the EJB-tier, any EJB should be able to
logg/audit stuff to track the user. The log-entry should be mapped to the
user, 'User1', and not to 'basic-user'.
If 'User2' enters the system, and is also mapped as 'basic-user', the
log-entry should say 'this was done by User2'.
/Anders
> -----Ursprungligt meddelande-----
> Fr�n: Bono, Chris [mailto:[EMAIL PROTECTED]]
> Skickat: den 10 november 2000 16:36
> Till: [EMAIL PROTECTED]
> �mne: Re: Providing additional context data to EJB's
>
>
> Engrstrom,
>
> Principal.getName() should return the name of the user logged
> in, whereas HttpServletRequest.isUserInRole() and
> EJBContext.isCallerInRole() should return a string
> representation mapped to an actual role in the underlying realm ( in
> the DD ).
>
> So in ejb-jar.xml or web.xml you can associate a
> <security-role-ref> of an actual role to a string that you can use in
> your code. Just another layer of indirection such as <resource-ref>s.
>
>
> Chris
>
>
>
> -----Original Message-----
> From: Engstr�m Anders [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 10, 2000 4:23 AM
> To: [EMAIL PROTECTED]
> Subject: SV: Providing additional context data to EJB's
>
>
> Hi!
> Thanks for your reply, Jerson.
>
> > You can use the request.getUserPrincipal().getName() for the
> > web tier and
> > context.getCallerPrincipa().getName() for the EJB tier to
> retrieve the
> > username of the authenticated user.
>
> This would be correct if each and every user connected to the EJB as
> himself, right. But we will be serving ~5000 users in the
> system, and the
> way we've thought of implementing the sign-on is to let the
> user enter the
> web-tier with the username/password that is unique for the user. The
> web-tier then looks up the user through some kind of
> SecurityManager (not
> fully modelled yet) and gets the correct role to use for the
> user. This role
> is then used to connect to the EJB-tier from the web-tier on
> behalf of the
> client.
>
> If I, in your example, would use
> ctx.getCallerPrincipal().getName() - wont
> this return the *role name*? We need some way to both allow
> the client to
> enter the EJB-tier as a predefined role, and also know in the
> EJB-tier which
> user is actually behind the role.
>
> I hope this makes the problem clearer. Also - if you have any
> design tips on
> how to best implement the above, please let me know :)
>
> /Anders
>
>
> > -----Original Message-----
> > Hi.
> >
> > This is my problem:
> >
> > We are building a multi-tier J2EE application using Oracles
> > iAs9 application
> > server. The clients will be both servlets, jsp-pages and
> applets. The
> > web-tier communicates with session EJB's on the application
> > server using
> > "light JavaBean mirrors of the EJBs" on the web-tier.
> >
> > Each user is assigned a role when logging in to the system.
> This role
> > (admin, registrator, guest etc.) is used in the EJB-container
> > to restrict
> > access to certain methods. The JavaBeans in the web-tier uses
> > the role to
> > look-up the EJB's in the appserver, thereby propagating the
> > role to the
> > EJB-container.
> >
> > The problem is that we need to propagate the unique user
> > identity to the
> > EJB-container as well (for logging and row-based access to
> > the database).
> > How do we do this in a good maner? I suppose we could send
> > the user-identity
> > with every method invocation, but that seems stupid :/ Is
> > there a way to put
> > this information into some kind of context that each EJB
> > within the session
> > can use? Or, can this be accomplished by setting some kind of
> > context when
> > looking up the home interface of the first EJB?
> >
> > Any ideas are welcome!
> >
> > Best Regards /Anders
> >
> > --
> > Anders Engstrom
> > WM-data eSolutions AB
> > [EMAIL PROTECTED]
> > http://www.wmdata.com
> > ====================
> >
> > ==============================================================
> > =============
> > 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".
>
> ==============================================================
> =============
> 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".
