Estoy configurando un servidor glassfish con una sola EJB3 como una burla de fondo para un POC. Todo estaba funcionando bien hasta que fui a agregar la autenticación básica. Planificar el texto id de usuario y contraseña, nada sofisticado para este trabajo. He añadido las siguientes anotaciones para el EJB:

@WebService(name = "Banking", serviceName = "Banking", targetNamespace = BANKING_NAMESPACE)
@DeclareRoles("user")
@Stateless
public class Banking {
    ...

    @RolesAllowed("user")
    @SOAPBinding(parameterStyle = ParameterStyle.BARE)
    @WebMethod(action = BANKING_NAMESPACE + "/logon", operationName = "logon")
    @WebResult(targetNamespace = XmlStrings.BANKING_MODEL_NAMESPACE)
    public LogonResponse logon(@WebParam(targetNamespace = XmlStrings.BANKING_MODEL_NAMESPACE) Logon request) throws WebServiceException {
     ...
    }
}

De acuerdo a lo que he leído de EJB3 especificación, esto es bastante común para hacer un servicio web SOAP.

Sin embargo, cuando me envía este xml:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mod="http://www.dhcbank.com/banking/model">
    <soapenv:Header>
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <wsse:UsernameToken wsu:Id="UsernameToken-79" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
                <wsse:Username>fred</wsse:Username>
                <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">fred</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
    </soapenv:Header>
    <soapenv:Body>
        <mod:logon/>
    </soapenv:Body>
</soapenv:Envelope>

Me sale el siguiente error como un error de SOAP:

java.lang.Exception: Client not authorized for invocation of public com.dhcbank.www.banking.schema.LogonResponse com.dhcbank.www.banking.Banking.logon(com.dhcbank.www.banking.schema.Logon) throws javax.xml.ws.WebServiceException

Y en el servidor glassfish registro:

[#|2010-10-10T12:49:27.497+1100|INFO|glassfish3.0.1|javax.enterprise.system.core.security|_ThreadID=41;_ThreadName=http-thread-pool-8080-(2);|JACC Policy Provider: Failed Permission Check, context(BankingEAR/Banking_war_internal)- permission((javax.security.jacc.EJBMethodPermission Banking logon,ServiceEndpoint,com.dhcbank.www.banking.schema.Logon))|#]

En el servidor glassfish admin pantallas he añadido un usuario llamado fred con un fred contraseña y se ha asignado a un grupos de usuario. Pero eso no funcionó.

Hice un poco más a la lectura que me sugirió que crear un sun-ejb-jar.xml archivo y agregarlo al archivo ear. Así que he creado con este contenido:

<sun-ejb-jar>
    <enterprise-beans>
        <ejb>
            <ejb-name>Banking</ejb-name>
            <webservice-endpoint>
                <port-component-name>Banking</port-component-name>
                    <login-config>
                        <auth-method>BASIC</auth-method>
                        <realm>file</realm>
                </login-config>
            </webservice-endpoint>               
        </ejb>
    </enterprise-beans>
</sun-ejb-jar>

Esto es lo más cerca que puedo decir, correcto. Sin embargo, no pude encontrar nada que me dijo lo que los valores de la port-component-name elemento debe ser. Así que no sé si yo tengo derecho.

De seguridad todavía no parecen estar trabajando y no puedo averiguar por qué. ¿Alguien tiene alguna experiencia con esto y puede que me apunte a lo que tengo mal o no se hace?

InformationsquelleAutor drekka | 2010-10-10

2 Comentarios

  1. 2

    Estoy asumiendo que su declarado rol «usuario» es el mismo nombre de la función en el archivo del reino? si no proporciona esta asignación en su descriptor:

    <sun-ejb-jar>
       <security-role-mapping>
         <role-name>user</role-name>
         <group-name>filerealm-group-name</group-name>
       </security-role-mapping>
       ...
    • Sí, me encontré con que también. Al principio yo tenía un grupo en el reino de archivo en glassfish se llama «usuario», así como un papel llamado «usuario» en el EJB. Luego traté de agregado de seguridad-función de asignación y cambio de la glasshfish grupo de «clientes», la asignación de «usuario» a «los clientes como por ejemplo. No trabajo. Cada vez que me vuelva a cargar el archivo ear que contiene el ejb veo los mensajes de Glassfish diciendo «No a los Directores asignados a la función de «usuario». Sospecho que este es el núcleo de la cuestión.
    • También veo un mensaje acerca de dos ejb (aunque sólo tengo uno) que se asigna con el mismo nombre. Si yo comente la @Stateless anotación, el mensaje desaparece. Sin embargo, todos los autenticación también se apaga. Así que me parece que a la necesidad de que la anotación.
  2. 1

    No creo que usted está creando actualmente el adecuado encabezado HTTP para la Autenticación Básica. No estoy seguro de cómo crear la solicitud SOAP, pero si usted está utilizando un JAX-WS cliente, el JAX-WS FAQ documentos los siguientes:

    P. ¿Cómo puedo realizar la autenticación básica en JAX-WS?

    Puede hacer lo siguiente:

    HelloService service = new HelloService();
    Hello proxy = (service.getHelloPort());
    ((BindingProvider)proxy).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "userfoo");
    ((BindingProvider)proxy).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "passbar");

    USERNAME_PROPERTY, PASSWORD_PROPERTY
    se utilizan principalmente para el servicio de
    las solicitudes. Creo que cuando se crea la instancia de
    Servicio, obtiene WSDL y el
    servidor devuelve 401. Usted podría tratar de
    cualquiera de las siguientes soluciones.

    1. El uso de java.net.Autenticador de clase en la aplicación cliente.
    2. Proporcionar un acceso local para el WSDL mediante catálogo. Hay un catálogo de
      muestra en la jax-ws distribución.
    3. Configurar web.xml para permitir que las solicitudes GET sin autenticación

    Y a menos que me equivoque, la usernametoken encajaría si el webservice espera que la autenticación en el encabezado SOAP, que no es el caso de acuerdo a su descripción.

    En otras palabras, para mí, actualmente no eres el envío de las credenciales para el BASIC auth.

    Véase también

    • Estoy usando SoapUI y el xml es lo que genera.
    • Sería esta ayuda: thewonggei.wordpress.com/2010/08/05/…
    • Okies, encontrado algunos errores en el xml porque yo de la mano escribió la sección de seguridad. Me he fijado aquellos en el código anterior y repetir en SoapUI. El mensaje Soap es correcta y este es el diseño correcto de los encabezados de ws-security. Ya he usado antes para la seguridad básica y en muchos SoapUI pruebas. Por lo general, agregar el usuario a la SoapUI proyecto y la puso sobre la solicitud Soap desde el SoapUI auth configuración. SoapUI, a continuación, genera este mensaje con el objeto incrustado ws-elementos de seguridad.
    • Mi punto era que nada en su pregunta permitido a la conclusión de que el HTTP encabezado para basic auth fue definido correctamente (el encabezado de ws-security es irrelevante para la cuestión), de ahí mi respuesta 🙂
    • Okies. Su respuesta fue que me confunde porque no he usado encabezados http para la autenticación de las solicitudes soap. Siempre usa ws-security lements en el encabezado SOAP como por encima. 🙂
    • No hay problema. autenticación Básica es un «puro HTTP» y que es necesario establecer un adecuado Authorization campo de encabezado HTTP. ¿Configurar SoapUI para que, como se sugiere en el otro enlace que se encuentra por encima de? ¿Qué se obtiene después de hacerlo?
    • Sí que se me confunde. Personas con las que he estado trabajando con se refiere a la ws-security texto sin autorización en los encabezados SOAP como la autenticación BÁSICA. 🙁 Ahora he trabajado fuera lo que estaba mal con el código y lo que estaba haciendo. Voy a publicar una respuesta de una vez he limpiado y filtran la información antigua.

Dejar respuesta

Please enter your comment!
Please enter your name here