Hi
Thanks for the replay, but I still don't quite understand how the target
service can verify that the saml assertion comes from the sts. Because here
the sts and target service have the same certificates and private key, but
in the real world would the target service have the same private key as the
sts. I think the sample would be much easier to follow if there was three
distinct keystores.
I notice in sanple 06 there are three keystores. Maybe this is more a
general ws-trust question and not specific to rampart, of course nice to
know how to do it in rampart.
cheers, Håkon
2009/3/17 Martin Gainty <mgai...@hotmail.com>
> the clients secure conversation takes place based on the characteristics
> of client.properties:
>
>
> org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
> org.apache.ws.security.crypto.merlin.keystore.type=jks
> org.apache.ws.security.crypto.merlin.keystore.password=aig_crooks
> org.apache.ws.security.crypto.merlin.file=client.jks
>
> the service secure conversation takes place based on the characteristics of
> service.properties:
>
> org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
> org.apache.ws.security.crypto.merlin.keystore.type=jks
> org.apache.ws.security.crypto.merlin.keystore.password=aig_crooks
> org.apache.ws.security.crypto.merlin.file=service.jks
>
> incoming requests from the client are processed by InflowSecurity callback
> public class PWCBHandler implements CallbackHandler {
>
> public void handle(Callback[] callbacks) throws IOException,
> UnsupportedCallbackException {
> for (int i = 0; i < callbacks.length; i++) {
> WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i];
>
> String id = pwcb.getIdentifer();
> if("client".equals(id)) {
> pwcb.setPassword("apache");
> } else if("service".equals(id)) {
> pwcb.setPassword("apache");
> }
> }
> }
>
> }
>
> client.jks contents:
> %RAMPART_HOME%\rampart-samples\keys>keytool -list -keystore client.jks
> Enter keystore password:
>
> Keystore type: JKS
> Keystore provider: SUN
>
> Your keystore contains 2 entries
>
> service, Aug 20, 2007, trustedCertEntry,
> Certificate fingerprint (MD5):
> 0A:0D:20:99:3E:D3:65:A8:50:CC:20:A6:CB:6F:33:06
> client, Aug 20, 2007, PrivateKeyEntry,
> Certificate fingerprint (MD5):
> 0C:EA:53:98:A5:15:B0:C8:5A:CD:4E:1C:87:A4:71:31
>
> service.jks contents:
> F:\Rampart\rampart-src-1.3\rampart-samples\keys>keytool -list -keystore
> service.
> jks
> Enter keystore password:
>
> Keystore type: JKS
> Keystore provider: SUN
>
> Your keystore contains 2 entries
>
> service, Aug 20, 2007, PrivateKeyEntry,
> Certificate fingerprint (MD5):
> 0A:0D:20:99:3E:D3:65:A8:50:CC:20:A6:CB:6F:33:06
> client, Aug 20, 2007, trustedCertEntry,
> Certificate fingerprint (MD5):
> 0C:EA:53:98:A5:15:B0:C8:5A:CD:4E:1C:87:A4:71:31
>
> Takk,
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note
>
>
> 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.
> This message is confidential and may be privileged. If you are not the
> intended recipient, we kindly ask you to please inform the sender. Any
> unauthorised dissemination or copying hereof is prohibited. This message
> serves for information purposes only and shall not have any legally binding
> effect. Given that e-mails can easily be subject to manipulation, we can not
> accept any liability for the content provided.
>
>
>
>
>
>
> > Date: Tue, 17 Mar 2009 16:40:10 +0100
> > Subject: Question about rampart samples05, verification of the token
> issued
> > From: hakon.sageh...@bccs.uib.no
> > To: axis-u...@ws.apache.org; rampart-dev@ws.apache.org
>
> >
> > Hi all,
> >
> > I've got some question about rampart sample 05, using the sts service.
> >
> > In the client the sts service is first called then the token is inserted
> in
> > the header and sent to the target service, my question is how does the
> > target service know that this token was issued by the sts service, is
> this
> > inside the SAML assertion?
> >
> > I'm sorry but I can't get my head around this. I would guess that the
> > digital signature from the request to the target service from the client
> is
> > based on the soap body for that request so this one
> >
> > <ns1:echo xmlns:ns1="http://sample05.policy.samples.rampart.apache.org";>
> > <param0>Hello world1</param0>
> > </ns1:echo>
> >
> > And if the target service is validating the SAML assertion and seeing
> that
> > the signature info in this is signed by the sts, how would one approach
> it,
> > if the target service does not accept a SAML token, or maybe a SMAL 2
> token.
> >
> >
> > Sorry if I did not phrase the question good enough, but hopefully someone
> > can debug it and answer.
> >
> > My naive idea is something like this: get token form sts signed, copy it
> to
> > the head of the next request to the target service, the target service
> uses
> > the public key to verify the signature and extract the token and on the
> > basis of this performs authrization operation.
> > Is this correct way of thinking about it?
> >
> > cheers, Håkon
> >
> >
> > --
> > Håkon Sagehaug, Scientific Programmer
> > Parallab, Bergen Center for Computational Science (BCCS)
> > UNIFOB AS (University of Bergen Research Company)
>
> ------------------------------
> Hotmail® is up to 70% faster. Now good news travels really fast. Find out
> more.<http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009>
>
--
Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)
