4 Replies Latest reply on May 4, 2005 1:02 PM by starksm64

    Exposing SLSB that has both checked and unchecked methods

    essington

      Is it possible to expose a SLSB as a web service that has both checked and unchecked methods?

      Once I add auth-method to the port-component of a bean, the whole service (all methods) require authentication (http authentication) however if I do not add auth-method none of the methods ask for authentication (http authentication) but the checked methods will fire off a soap fault rather than requesting authentication.

      Even if I preemptively supply my credentials (http auth), when auth-method has not been declared, that information does not get passed on to the EJB layer and I still get an authentication error.

      So it seems that authentication for a webservice endpoint is an all or nothing sort of thing? Is this expected.

      -jason

        • 1. Re: Exposing SLSB that has both checked and unchecked method
          thomas.diesler

          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

            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

              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

                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.