-
1. Re: Exposing SLSB that has both checked and unchecked method
thomas.diesler May 4, 2005 12:18 PM (in response to essington)Yes, this is expected behaviour because the security constraints of an EJB endpoint are associated with the /context-root of its generated web app.
This is an undesired side effect of coupleing security to a specific transport (HTTP). -
2. Re: Exposing SLSB that has both checked and unchecked method
starksm64 May 4, 2005 12:26 PM (in response to essington)We could think about a jboss-web.xml specific mapping that allowed for finer grained control of the auth constraints, but this would require exposing the method as part of the endpoint url since that is the level of granularity needed to differentiate between authenticated and unauthenticated requests. I'm sure this opens up a portability nightmare as I don't this can be expressed in the wsdl for the service, or can it?
-
3. Re: Exposing SLSB that has both checked and unchecked method
thomas.diesler May 4, 2005 12:36 PM (in response to essington)It would require defining a portType per operation - as you say a nightmare.
How about defining just two portTypes, one for checked another for unchecked operations. Then we could associate different port-component-uri with the WSDL ports that use these portTypes. You would have two SEIs and just one endpoint implemenation.
Finally this would justify support for multiple web context roots for EJB endpoint deployments - something we talked about a while ago. -
4. Re: Exposing SLSB that has both checked and unchecked method
starksm64 May 4, 2005 1:02 PM (in response to essington)You don't need a seperate context root just for the checked vs unchecked because your two port-component-uri elements could be mapped to seperate security-contraint elements in the web.xml. For example:
<jboss> <session> <ejb-name>BasicSecuredSLSB</ejb-name> <jndi-name>ejb/BasicSecuredSLSB</jndi-name> <port-component> <port-component-name>BasicSecured</port-component-name> <port-component-uri>/ws4ee-samples-ejb/BasicSecured</port-component-uri> <auth-method>BASIC</auth-method> <auth-constraint> <description>Only authenticated users can access secure content</description> <role-name>AuthenticatedUser</role-name> </auth-constraint> <transport-guarantee>NONE</transport-guarantee> </port-component> <port-component> <port-component-name>Unsecured</port-component-name> <port-component-uri>/ws4ee-samples-ejb/Unsecured</port-component-uri> <transport-guarantee>NONE</transport-guarantee> </port-component> </session> </jboss>
would map to a web.xml with a context root of /ws4ee-samples-ejb and the following security-constraint elements:<web-app> <security-constraint> <web-resource-collection> <web-resource-name>BasicSecured</web-resource-name> <url-pattern>/BasicSecured/*</url-pattern> </web-resource-collection> <auth-constraint> <description>Only authenticated users can access secure content</description> <role-name>ExternalAuthUser</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Unsecured</web-resource-name> <url-pattern>/Unsecured/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>
Only one port-component can specify an auth-method, or they have to be the same as there can only be one auth-method per web app. Having multiple forms of authentication for a single ejb is what would require multiple web deployments/context-roots.