Apologies for the delay in my response ! According to the scenario explained in the original post ... a web service calls secured methods on the EJB. When the subject is authenticated into the web service by Rampart using the callback handler provided by the user ... a java.security.Principal instance will be available in the rampart processing results [1].
IMHO at this point if we want to call the secured method on the EJB, the web service developer will have to set the Principal instance in a context that the J2EE container uses to extract the authenticated Principal. Thanks, Ruchith [1] http://www.wso2.org/library/169 On 4/18/07, Tony Dean <[EMAIL PROTECTED]> wrote:
right, you can configure basic auth security constraints in web.xml... but, as for web services clients send credentials in security header, not http header. as such, container needs to be aware of this... native web service engines like websphere, weblogic have integrated this type of security into their container by letting you configure security constraints on individual web services... eg., webservice A must supply UsernameToken. the container will then parse the UsernameToken and perform the necessary authentication as configured with these credentials... my question to Ruchith would be how can Axis2/rampart integrate in this way with the container since its only a another servlet to the native container... thanks. > -----Original Message----- > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 18, 2007 10:12 AM > To: Tony Dean > Cc: axis-user@ws.apache.org > Subject: Re: AXIS2 and LoginModule > > Tony, > > you can configure the security constraints in web.xml since > Axis2 is just another servlet. What's missing is we don't do > any authorization checks from inside Axis2. > > Above info is w/o rampart. I'll let Ruchith chime in regarding that. > > thanks, > -- dims > > On 4/18/07, Tony Dean <[EMAIL PROTECTED]> wrote: > > hi dims, > > > > so today, if you wanted to configure a JAAS security domain > for your Jboss axis2 servlet as follows: > > > > jboss-web.xml > > ------------- > > <jboss-web> > > <security-domain>java:/jaas/some_JAAS_context</security-domain> > > </jboss-web> > > > > how can I put security constraints on the axis2 servlet > such that the security header for all incoming web service > requests is parsed, and the realized credentials are then > used to perform JAAS authentication as configured by the container. > > > > for webApps this is done by configuring secuirty > constraints in web.xml (eg., basic auth). then the container > requires basic authentication for the configured URLS and the > realized credentials are used to perform JAAS authentication > as configured by the container. if authentication is > successful, the impl class can acquire the authenticated > Subject for further authorization checks. > > > > I do not know how Axis2 would integrate this behavior into > the container. You would have to configure rampart to > require UsernameToken. Once rampart obtained credentials, it > would somehow have to pass them unto the container for JAAS > authentication. How this would be done is unknown to me. > > > > --Tony > > > > > > > > > -----Original Message----- > > > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, April 18, 2007 9:21 AM > > > To: axis-user@ws.apache.org > > > Subject: Re: AXIS2 and LoginModule > > > > > > we do have an issue in jira - > > > https://issues.apache.org/jira/browse/AXIS2-164 > > > > > > -- dims > > > > > > On 4/18/07, Tony Dean <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I wasn't aware that Axis2 could hook into JAAS... when you > > > develop a > > > > J2EE web service, the container takes care of parsing > the security > > > > header for credentials and using those credentials to > authenticate > > > > against a defined login context (ie., loginModules defined for > > > > that login context). If authentication is successful, > a Subject > > > > is available for this current call thread. This Subject is > > > used for determining webApp and EJB authorization. > > > > Axis2 does not provide such integration to my knowledge. > > > It would be > > > > great if it did. Anyone, please correct me if I am wrong. > > > > > > > > --Tony > > > > > > > > > > > > ________________________________ > > > > From: Joseph L Shimkus [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, April 18, 2007 8:16 AM > > > > To: axis-user@ws.apache.org > > > > Subject: AXIS2 and LoginModule > > > > > > > > > > > > > > > > I have implemented the Rampart module in my AXIS2 > > > webservice with my > > > > own CallbackHandler. However, once authenticated my > > > webservice calls > > > > secured methods on an EJB session bean which fail. It appears > > > > that the LoginModule which normal stores the authenticated > > > > principals in context is not doing so, or not doing so in a way > > > > which the > > > EJBs can > > > > understand. Since the Rampart configuration only exposed the > > > > CallbackHandler class, I'm unsure what class it is using or > > > if I'm able to change it. > > > > > > > > Does anyone know what the behavior of the Rampart > > > LoginModule is? Or > > > > how I can achieve a call from the web service to a secured > > > EJB method? > > > > > > > > Joe Shimkus > > > > > > > > -------------------------------------------------------------------- > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > > > Developers > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web > Services Developers > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- www.ruchith.org www.wso2.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
