Hi, Is the following ws-securepolicy suppported by Neethi? In this scenario I basically want the STS to create a SecurityContextToken and associate it with a RequestedProofToken binarySecret key. Once this is returned I would expect Neethi to use this key to encrypt/sign the data as configured in the policy. The actual security header that is sent to the target should contain the returned SecurityContextToken that is referenced by the encrypt and signing information.
<wsp:Policy wsu:Id="myPolicy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";> <wsp:ExactlyOne> <wsp:All> <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:IssuedToken sp:IncludeToken=".../AlwaysToRecipient"> <sp:Issuer> <wsa:EndpointReference> <wsa:Address>http://host:8080/context/mySTS</wsa:Address> </wsa:EndpointReference> </sp:Issuer> <sp:RequestSecurityTokenTemplate> <!-- request symmetric key for the issued token --> <wst:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</wst:KeyType> <wst:TokenType>...SecurityContextToken</wst:TokenType> </sp:RequestSecurityTokenTemplate> </sp:IssuedToken> </wsp:Policy> </sp:ProtectionToken> </wsp:Policy> </sp:SymmetricBinding> <sp:SignedParts> <sp:Header/> </sp:SignedParts> <sp:EncryptedParts> <sp:Header/> </sp:EncryptedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> I don't think that this policy specifies how the client authenticates itself to the STS. Can this be specified? I believe the RequestSecurityTemplate/TokenType specifies that the client requires the STS to return a SecurityContextToken. Is that correct? This will cause the client to request the appropriate token type in the request as shown below. Suppose the client sends the following STS request (UsernameToken authentication): [assuming SSL channel] <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; soapenv:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="UsernameToken-31156635"> <wsse:Username>...</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>...</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body> <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust";> <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType> <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType> <wst:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>...</wsu:Created> <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>...</wsu:Expires> </wst:Lifetime> </wst:RequestSecurityToken> </soapenv:Body> </soapenv:Envelope> Does the above policy require the STS to return an associated RequestedProofTaken/BinarySecret along with the response since it specifies a RequestSecurityTokenTemplate/KeyType of symmetric. How is this information specified to the STS? If the STS returns response as follows: <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header /> <soapenv:Body> <wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust";> <wst:RequestedSecurityToken> <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="sctId-20739678"> <wsc:Identifier>UUID</wsc:Identifier> </wsc:SecurityContextToken> </wst:RequestedSecurityToken> <wst:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>...</wsu:Created> <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>...</wsu:Expires> </wst:Lifetime> <wst:RequestedProofToken> <wst:BinarySecret>jshjuENog3UX7f0wfeE8RoODIoRIkqX4Jc5MbLOntTY=</wst:BinarySecret> </wst:RequestedProofToken> </wst:RequestSecurityTokenResponse> </soapenv:Body> </soapenv:Envelope> Will the client (Neethi processor) use the BinarySecret to secure the message? That is, will the client sign and encrypt the Header (as specified in the policy) with this BinarySecret key? And also attach the returned SecurityContextToken to the security header so that the key information for signing/encrypting references this token? In this scenario the target security processor will have to know the binary secret. That's no problem, but how can you programatically give this key to Rampart such that it could decrypt the data and verify the signature with this key? --------------------------------------------------------------------------------------------------------------- I have already asked this before, but I'd like conformation that the following scenario is not supported by ws-securepolicy (Neethi). I know there is probably not a standard way to specify that you would like the STS to return a UsernameToken password digest. But, suppose you configured the STS to return such a token (password digest computed from secret which is also know to the target service). You should be able to specify secure policy (Neethi) that you want the returned token to be added to the outbound request... i guess as a supporting token. Is this possible? The way that I currently have this coded is the following: The STS returns a SecurityContextToken and a RequestedProofToken/BinarySecret. From this information my client module STS interceptor creates the UsernameToken (password digest) and adds it to the header before sending it along to the target service. However the WS-Trust spec says "In general, the returned token should be considered opaque to the requestor". I am violating this statement so I'm wondering if I can generate such a token at the STS and have the client just attach it to the security header as a supporting token. Is that a more standard way to accomplish this with security/policy? --------------------------------------------------------------------------------------------------------------- Tony Dean SAS Institute Inc. 919.531.6704 [EMAIL PROTECTED] SAS... The Power to Know http://www.sas.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
