You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Tony Dean <To...@sas.com> on 2007/05/15 00:23:34 UTC
[Axis2] Neethi/Rampart
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
tony.dean@sas.com
SAS... The Power to Know
http://www.sas.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org