A SOAP fault is returned to the client. See section 12 "Error Handling" here:
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf For example: faultcode: wsse:FailedAuthentication faultstring: The security token could not be authenticated or authorized Colm. On Thu, Dec 2, 2010 at 10:41 AM, Schneider Christian <[email protected]> wrote: > Just out of curiosity... How should you handle an authorization fault like > missing authentication, wrong credentials or not authorized in the > ws-security case. > > For http auth protocols we use 401 and 403 response codes. How is this > handled in the ws security case? Or does the spec only say how to transmit > the data? > > Best regards > > Christian > > > > Christian Schneider > Informationsverarbeitung > Business Solutions > Handel und Dispatching > > Tel : +49-(0)721-63-15482 > > EnBW Systeme Infrastruktur Support GmbH > Sitz der Gesellschaft: Karlsruhe > Handelsregister: Amtsgericht Mannheim HRB 108550 > Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck > Geschäftsführer: Jochen Adenau, Hans-Günther Meier > > > -----Ursprüngliche Nachricht----- > Von: Colm O hEigeartaigh [mailto:[email protected]] > Gesendet: Donnerstag, 2. Dezember 2010 11:31 > An: [email protected] > Betreff: Re: Nonce encoding > >> By outputting the EncodingType like above, we are wasting >> bandwidth by outputting redundant information, but it is completely valid. > > It may be a waste of bandwidth, but the Basic Security Profile spec requires > it: > > http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html#UsernameTokenNonce > > "R4220 Any NONCE MUST specify an EncodingType attribute. " > >> Thanks for the response Daniel, but how can I told WSS4JOutInterceptor not to >> use Base64 encoding for the 'Nonce'? > > No, only Base64 encoding is supported. > > Colm. > > > On Wed, Dec 1, 2010 at 8:11 PM, Daniel Kulp <[email protected]> wrote: >> On Wednesday 01 December 2010 2:52:12 pm FelipeGC wrote: >>> Hi all! >>> >>> I'm writing a client application that needs to authenticate in the server >>> using WSS Username Token Profile. The password must be encrypted unsing the >>> password digest as described in the specification: Base64 ( SHA-1 ( nonce + >>> created + password ) ). >>> >>> For that purpose I'm using the WSS4JOutInterceptor as follows: >>> >>> Map<String, Object> outProps = new HashMap<String, Object>(); >>> String username = "aUsername"; >>> String password = "aPassword"; >>> outProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN); >>> outProps.put(WSHandlerConstants.USER, username); >>> outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_DIGEST); >>> outProps.put(WSHandlerConstants.PW_CALLBACK_REF, new >>> ClientPasswordCallbackHandler(username, password)); >>> WSS4JOutInterceptor wssInterceptor = new WSS4JOutInterceptor(outProps); >>> >>> The resulting XML is being created with the elements: 'Username', >>> 'Password', 'Nonce' and 'Created'. The 'Nonce' is beign created like this: >>> >>> <wsse:Nonce >>> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- >>> message-security-1.0#Base64Binary">kG8i5U4s1I6AbolCG/AYkw==</wsse:Nonce> >>> >>> As I undertand this is right, but the server is not authenticating my >>> request. The guys responsible for the server said that the 'Nonce' must not >>> be encoded in Base64 and that encoding is optional. This is right? >> >> If you look at the UsernameToken profile specification: >> http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf >> Line 249 clearly states that it IS optional, but if unspecified, the default >> is Base64. By outputting the EncodingType like above, we are wasting >> bandwidth by outputting redundant information, but it is completely valid. >> Thus, they are wrong. Base64 is the correct encoding for it. >> >> >> Dan >> >> >>> >>> What I want to know is: there's any other way to send the 'Nonce' using >>> another encoding other than Base64? >>> >>> Thanks, >>> FelipeGC >> >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> >
