looks like rampart can transmit and receive Created and Expired Timestamps in
RequestSecurityToken (OASIS WS-Trust)
<soapenv:Body>
<wst:RequestSecurityToken
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust";>
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
<wsp:AppliesTo
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
<wsa:EndpointReference
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing";>
<wsa:Address>http://localhost:8081/axis2/services/sample04</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:Lifetime>
<wsu:Created
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>2008-06-23T13:25:33.580Z</wsu:Created>
<wsu:Expires
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>2008-06-23T13:30:33.580Z</wsu:Expires>
</wst:Lifetime>
<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>
<wst:Entropy>
<wst:BinarySecret
Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce";>LvNYXcA6HKhPIAzUrsswYA==</wst:BinarySecret>
</wst:Entropy>
<wst:ComputedKeyAlgorithm>http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1</wst:ComputedKeyAlgorithm>
</wst:RequestSecurityToken>
</soapenv:Body>
but we need to add IncludeTimestamp to bootstrapPolicy e.g.
<sp:IncludeTimestamp/>
if the bootstrapPolicy implements
SymmetricBindinghttp://blog.sweetxml.org/2008/01/runnning-axis2-rampart-sample-04.html
files:
src\site\resources\samples\policy\sample04.xml (policy)
src\site\resources\samples\msgs\rst04.xml (sample Request)
src\site\resources\samples\msgs\rstr04.xml (sample Response)
rampart-samples\policy\build.xmlrun service.04
<!-- Sample Service 04 -->
<target name="service.04" if="env.AXIS2_HOME" depends="check.dependency">
<create.service.repo sample.number="04"/>
</target>
rampart-samples\policy\build.xml
then run client.04
<!-- Sample Client 04 -->
<target name="client.04" if="env.AXIS2_HOME" depends="check.dependency">
<create.and.run.client sample.number="04"/>
</target>
does this fit your testcase
Martin
______________________________________________
Please...do not alter or disrupt this message..Thank You
From: [email protected]
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback
Date: Wed, 16 Jan 2013 09:02:46 -0500
George, Yes that was the obvious first step which I thought would make life
easy. But doing so returns null and that’s when I started looking into this
issue. I was hoping to fix it by finding where these values are actually set in
the code (I think its in WSS4J) but I could not (find it that is). I haven’t
given up yet but it’s a huge project and I am not that familiar with it. I
assume it returns null because (according to comments in the code) it states
the callback handler (me) shall set the password. I assume the getPassword()
method is then used by the library later. But when I get the callback,
cb.getPassoword() returns null. Brian From: George Stanchev
[mailto:[email protected]]
Sent: Wednesday, January 16, 2013 8:57 AM
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback
Brian, According to the article Martin referred you to, it is possible. You can
access it on the server side via WSPasswordCallback#getPassword() getter,
perform your own validation and throw an UnsupportedCallbackException with a
proper message. See the last callback sample code under [1] George [1]
http://wso2.org/library/3733 From: Brian Reinhold
[mailto:[email protected]]
Sent: Wednesday, January 16, 2013 6:50 AM
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback
Well, that’s what I am doing for a current work a round. I am performing the
hash on the client side and sending as ‘PasswordText’. However, I hope that
this is supported by the WS-Trust standard so it will not cause
interoperability issues. If it is possible to specify that the client use a
SHA-1 in a clear text password send via WS-Policy and WS-SecurePolicy, then
that will be a solution. I have not checked your blog yet but if I can do that,
it will be a good solution. Still I think it would have been nice to support
the option for the service to obtain the sent Password. Many simple clients are
likely to only a single policy and that tends to be the clear text option.
Brian From: George Stanchev [mailto:[email protected]]
Sent: Wednesday, January 16, 2013 8:38 AM
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback Hi
Brian, Can you send the password as a digest [1] in the message and then
provide the hash instead? Admitting, this will not work if you’re using a
different hashing algorithm than SHA-1 for your stored passwords… George [1]
http://blog.rampartfaq.com/2009/08/how-to-ask-for-hashed-password-in.html From:
Brian Reinhold [mailto:[email protected]]
Sent: Tuesday, January 15, 2013 3:33 PM
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback
Martin, I looked in the code and it stated that the callback must provide the
password. This is not good for a service that does not store the password but
only a password digest (for security reasons). That means the service does not
know the user’s password and a hacker cannot obtain it by hacking into the
service’s database. The hacker might be able to obtain a single users password
hidden in TLS (unlikely) but that would be only one. The idea would be to get
the password, perform the digest and if it matches the stored digest, it is
okay. Set the password, otherwise err. Brian From: Martin Gainty
[mailto:[email protected]]
Sent: Tuesday, January 15, 2013 4:26 PM
To: [email protected]
Subject: RE: Rampart STS Username service not returning password in callback Hi
Brian
assuming rampart implements this configuration:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing";>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soapenv:mustUnderstand="1">
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="Timestamp-12468716">
<wsu:Created>2008-06-23T13:17:13.841Z</wsu:Created>
<wsu:Expires>2008-06-23T13:22:13.841Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="UsernameToken-31571602">
<wsse:Username>alice</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>bobPW</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<wsa:To>http://localhost:8081/axis2/services/sample01</wsa:To>
<wsa:MessageID>urn:uuid:AEDBA74A8D1FC94B631214227032877</wsa:MessageID>
<wsa:Action>urn:echo</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<ns1:echo xmlns:ns1="http://sample01.policy.samples.rampart.apache.org";>
<param0>Hello world</param0>
</ns1:echo>
</soapenv:Body>
</soapenv:Envelope>
public void handle(Callback[] callbacks) throws
IOException,UnsupportedCallbackException {
for (int i = 0; i < callbacks.length; i++) {
//When the server side need to authenticate the user
WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i];
if (pwcb.getUsage() == WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) {
if(pwcb.getIdentifier().equals("bob") &&
pwcb.getPassword().equals("bobPW")) {
http://wso2.org/library/3733
HTH.,
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.Ce message est confidentiel et peut être
privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec
bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non
autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant
donné que les email peuvent facilement être sujets à la manipulation, nous ne
pouvons accepter aucune responsabilité pour le contenu fourni.
> From: [email protected]
> To: [email protected]
> Subject: Rampart STS Username service not returning password in callback
> Date: Tue, 15 Jan 2013 15:00:53 -0500
>
> Has anyone else had this problem? I have a simple STS Username token request
> for a SAML token where the username token is as follows:
>
> <wsse:UsernameToken wsu:Id="UsernameToken-ID">
> <wsse:Username>myName</wsse:Username>
> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">myPassword</wsse:Password>
> </wsse:UsernameToken>
>
>
> On the receive side there is a callback to verify the username token
>
> public void handle(Callback[] callbacks) throws IOException,
> UnsupportedCallbackException
> {
> for(Callback callback: callbacks)
> {
> WSPasswordCallback cb = (WSPasswordCallback)callback;
> int callbackType = cb.getUsage();
> switch(callbackType)
> {
> case WSPasswordCallback.USERNAME_TOKEN:
> try
> {
> if(cb.getType().equals(WSConstants.PASSWORD_TEXT))
> {
> String myPassword = cb.getPassword();
> ...
>
> The returned 'myPassword' is null. Any ideas why?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/13No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/13No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13
