Question on SOAP client configuration for an STS

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Question on SOAP client configuration for an STS

Glen Mazza
Hello, the Metro Users Guide, in discussing client-side security configuration when using an STS[1], has us do this step:

"6.  Provide the service's certificate by pointing to an alias in the client truststore. For development purposes, click the Truststore button,, click the Load Aliases button for the truststore and select xws-security-server from the Alias list."

Question:  Why do I need to provide the service's certificate--is it:
(1) Because transport-layer security will be used between client and service (after the client gets the SAML token from the STS), and it is this truststore (rather than the default cacerts file with the JRE) that is used to obtain the service's public key?

or

(2) Because message-layer security will be used between client and service after the client gets the SAML token?

Thanks,
Glen

[1] https://jax-ws.dev.java.net/guide/Configuring_A_Secure_Token_Service__STS_.html#gghnt
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
This step is only needed in the case of message level security with service certificate used to protect the messages.

You can update the doc for this.

Some other steps in that section may have the same problems.
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=394985

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

Glen Mazza
Thanks Jiandong. I can understand using transport-layer encryption so the SOAP message would be encrypted during transmission from the client to the service--but wouldn't message-level encryption require a trust relationship between client and service, and, hence, largely defeat the purpose of using an STS to begin with?

I guess the doc could be updated here, but it would have to be done carefully to indicate that either message-layer or transport-layer security should be used.

Also, just to make sure I'm understanding things correctly:

1.) The client- and service-side configuration of truststores and keystores within NetBeans is *never* used for transport-layer encryption, it is only for message-layer?  I.e., transport-layer encryption requires placing the server's certificate in the client JRE's cacerts file--the truststore/keystore config options in NetBeans won't help here.

2.) The server/service public key that the client uses for encryption is different between transport-layer and message-layer encryption.  For transport-layer, the client would be using the server machine's public key (the key of the machine hosting the web service), but for message-layer the client would tend to use a web service-specific public key (and not the one of the server machine itself)?  Or is the service-side key the same either way?

Thanks,
Glen

metro-3 wrote
This step is only needed in the case of message level security with service certificate used to protect the messages.

You can update the doc for this.

Some other steps in that section may have the same problems.
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
>
> Thanks Jiandong. I can understand using
> transport-layer encryption so the
> SOAP message would be encrypted during transmission
> from the client to the
> service--but wouldn't message-level encryption
> require a trust relationship
> between client and service, and, hence, largely
> defeat the purpose of using
> an STS to begin with?

No. The client can still trust the certificate of the service and use it to secure the messages (same thing for SSL). But the client credential can't be used with the service
directly so it has go to the STS to get one that can be used with the service.

>
> I guess the doc could be updated here, but it would
> have to be done
> carefully to indicate that either message-layer or
> transport-layer security
> should be used.
Ok. I will take a shot trying to make it clear in what cases each of the steps
required. Your feedback is valuable.

>
> Also, just to make sure I'm understanding things
> correctly:
>
> 1.) The client- and service-side configuration of
> truststores and keystores
> within NetBeans is *never* used for transport-layer
> encryption, it is only
> for message-layer?  I.e., transport-layer encryption
> requires placing the
> server's certificate in the client JRE's cacerts
> file--the
> truststore/keystore config options in NetBeans won't
> help here.
Yes, that should be case. Although on Glassfish, the truststore/keystore are the cacerts.jks and keystore.jks in GF/domains/domain/config.

You may change it by configuring the Glassfish SSL options.


>
> 2.) The server/service public key that the client
> uses for encryption is
> different between transport-layer and message-layer
> encryption.  For
> transport-layer, the client would be using the server
> machine's public key
> (the key of the machine hosting the web service), but
> for message-layer the
> client would tend to use a web service-specific
> public key (and not the one
> of the server machine itself)?  Or is the
> service-side key the same either
> way?
It depends. They may be the same.

>
> Thanks,
> Glen
>
>
> metro-3 wrote:
> >
> > This step is only needed in the case of message
> level security with
> > service certificate used to protect the messages.
> >
> > You can update the doc for this.
> >
> > Some other steps in that section may have the same
> problems.
> >
>
> --
> View this message in context:
> http://old.nabble.com/Question-on-SOAP-client-configur
> ation-for-an-STS-tp28114970p28116899.html
> Sent from the Metro - Users mailing list archive at
> Nabble.com.
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=395086

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

Glen Mazza
metro-3 wrote
>
> Thanks Jiandong. I can understand using
> transport-layer encryption so the
> SOAP message would be encrypted during transmission
> from the client to the
> service--but wouldn't message-level encryption
> require a trust relationship
> between client and service, and, hence, largely
> defeat the purpose of using
> an STS to begin with?

No. The client can still trust the certificate of the service and use it to secure the messages (same thing for SSL). But the client credential can't be used with the service
directly so it has go to the STS to get one that can be used with the service.
OK, just to clarify, message-level encryption also means that the service provider will encrypt the SOAP response back in a manner that only the SOAP client can read it.  But since the web service provider is not directly trusting the SOAP client (stated another way, the client's public key is not in the web service provider's truststore), the web service provider will have the SOAP client's public key in the SAML token returned by the STS so it can do that encryption?

Otherwise, I can't see how, if the web service provider does *not* have the client's public key in its truststore, it can message-level encrypt the SOAP response for only that particular client to read it.

Thanks,
Glen
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

Glen Mazza

Glen Mazza wrote
metro-3 wrote
>
> Thanks Jiandong. I can understand using
> transport-layer encryption so the
> SOAP message would be encrypted during transmission
> from the client to the
> service--but wouldn't message-level encryption
> require a trust relationship
> between client and service, and, hence, largely
> defeat the purpose of using
> an STS to begin with?

No. The client can still trust the certificate of the service and use it to secure the messages (same thing for SSL). But the client credential can't be used with the service
directly so it has go to the STS to get one that can be used with the service.
OK, just to clarify, message-level encryption also means that the service provider will encrypt the SOAP response back in a manner that only the SOAP client can read it.  But since the web service provider is not directly trusting the SOAP client (stated another way, the client's public key is not in the web service provider's truststore), the web service provider will have the SOAP client's public key in the SAML token returned by the STS so it can do that encryption?

Otherwise, I can't see how, if the web service provider does *not* have the client's public key in its truststore, it can message-level encrypt the SOAP response for only that particular client to read it.

Thanks,
Glen
Also, one more question to add to this:  if we are using message-layer security and *not* placing the client certificate in the server's truststore, that implies that the SAML subject confirmation method must be holder-of-key and *not* sender-vouches, because only the former has the client key info necessary for the service to properly encrypt the SOAP response, correct?

Thanks,
Glen
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
In reply to this post by Glen Mazza
>
>
> metro-3 wrote:
> >
> >>
> >> Thanks Jiandong. I can understand using
> >> transport-layer encryption so the
> >> SOAP message would be encrypted during
> transmission
> >> from the client to the
> >> service--but wouldn't message-level encryption
> >> require a trust relationship
> >> between client and service, and, hence, largely
> >> defeat the purpose of using
> >> an STS to begin with?
> >
> > No. The client can still trust the certificate of
> the service and use it
> > to secure the messages (same thing for SSL). But
> the client credential
> > can't be used with the service
> > directly so it has go to the STS to get one that
> can be used with the
> > service.
> >
>
> OK, just to clarify, message-level encryption also
> means that the service
> provider will encrypt the SOAP response back in a
> manner that only the SOAP
> client can read it.

Exactly.

> But since the web service
> provider is not directly
> trusting the SOAP client (stated another way, the
> client's public key is not
> in the web service provider's truststore), the web
> service provider will
> have the SOAP client's public key in the SAML token
> returned by the STS so
> it can do that encryption?
>
> Otherwise, I can't see how, if the web service
> provider does *not* have the
> client's public key in its truststore, it can
> message-level encrypt the SOAP
> response for only that particular client to read it.

This is what the SymmetricBinding in WS-SecurityPolicy about. It in turn relies on WS-Security 1.1.

It goes like this:

1. The client create a ephemeral  symmetric key (A). Then it use A to encrypt the request message and use
the server certificate to encrypt A with an EncryptedKey element.

2. Server decrypt the EncryptedKey with  its private key  to obtain A. It then use A to decrypt the encrypted message.

3. Server encrypt the response message with A.

4. Client decrypt the response message with A.
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=395244

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
In reply to this post by Glen Mazza
> Also, one more question to add to this:  if we are
> using message-layer
> security and *not* placing the client certificate in
> the server's
> truststore, that implies that the SAML subject
> confirmation method must be
> holder-of-key and *not* sender-vouches,
Yes, in the case that the requester has now credential trusted by the server. You have to be holder of key or bearer.

> because only
> the former has the
> client key info necessary for the service to properly
> encrypt the SOAP
> response, correct?

See my answer to the your previous post.

>
> Thanks,
> Glen
>
> --
> View this message in context:
> http://old.nabble.com/Question-on-SOAP-client-configur
> ation-for-an-STS-tp28114970p28131655.html
> Sent from the Metro - Users mailing list archive at
> Nabble.com.
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=395245

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
In reply to this post by metro-3
> >
> >
> > metro-3 wrote:
> > >
> > >>
> > >> Thanks Jiandong. I can understand using
> > >> transport-layer encryption so the
> > >> SOAP message would be encrypted during
> > transmission
> > >> from the client to the
> > >> service--but wouldn't message-level encryption
> > >> require a trust relationship
> > >> between client and service, and, hence, largely
> > >> defeat the purpose of using
> > >> an STS to begin with?
> > >
> > > No. The client can still trust the certificate
> of
> > the service and use it
> > > to secure the messages (same thing for SSL). But
> > the client credential
> > > can't be used with the service
> > > directly so it has go to the STS to get one that
> > can be used with the
> > > service.
> > >
> >
> > OK, just to clarify, message-level encryption also
> > means that the service
> > provider will encrypt the SOAP response back in a
> > manner that only the SOAP
> > client can read it.
>
> Exactly.
>
> > But since the web service
> > provider is not directly
> > trusting the SOAP client (stated another way, the
> > client's public key is not
> > in the web service provider's truststore), the web
> > service provider will
> > have the SOAP client's public key in the SAML
> token
> > returned by the STS so
> > it can do that encryption?
> >
> > Otherwise, I can't see how, if the web service
> > provider does *not* have the
> > client's public key in its truststore, it can
> > message-level encrypt the SOAP
> > response for only that particular client to read
> it.
>

To be more precise, what you described above is one option (AsymmetricBinding based on WS-Security 1.0), SymmetricBinding is more efficient. With it
the issued SAML asserion can be a supporting token for authentication purpose.

> This is what the SymmetricBinding in
> WS-SecurityPolicy about. It in turn relies on
> WS-Security 1.1.
>
> It goes like this:
>
> 1. The client create a ephemeral  symmetric key (A).
> Then it use A to encrypt the request message and use
> the server certificate to encrypt A with an
> EncryptedKey element.
>
> 2. Server decrypt the EncryptedKey with  its private
> key  to obtain A. It then use A to decrypt the
> encrypted message.
>
> 3. Server encrypt the response message with A.
>
> 4. Client decrypt the response message with A.
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=395276

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

Glen Mazza
In reply to this post by metro-3
metro-3 wrote
> But since the web service
> provider is not directly
> trusting the SOAP client (stated another way, the
> client's public key is not
> in the web service provider's truststore), the web
> service provider will
> have the SOAP client's public key in the SAML token
> returned by the STS so
> it can do that encryption?
>
> Otherwise, I can't see how, if the web service
> provider does *not* have the
> client's public key in its truststore, it can
> message-level encrypt the SOAP
> response for only that particular client to read it.

This is what the SymmetricBinding in WS-SecurityPolicy about. It in turn relies on WS-Security 1.1.

It goes like this:

1. The client create a ephemeral  symmetric key (A). Then it use A to encrypt the request message and use
the server certificate to encrypt A with an EncryptedKey element.

2. Server decrypt the EncryptedKey with  its private key  to obtain A. It then use A to decrypt the encrypted message.

3. Server encrypt the response message with A.

4. Client decrypt the response message with A.
[Message sent by forum member 'jdg6688']
Oh, I see--thanks, I wasn't aware of this process.

Glen
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

Glen Mazza
In reply to this post by metro-3
metro-3 wrote
> Also, one more question to add to this:  if we are
> using message-layer
> security and *not* placing the client certificate in
> the server's
> truststore, that implies that the SAML subject
> confirmation method must be
> holder-of-key and *not* sender-vouches,
Yes, in the case that the requester has now credential trusted by the server. You have to be holder of key or bearer.

> because only
> the former has the
> client key info necessary for the service to properly
> encrypt the SOAP
> response, correct?

See my answer to the your previous post.
>
Jiandong, as you explained to me earlier, because of the SymmetricBinding mechanism it is not necessary for the web service provider to have the client's public key in order to do message-level encryption between it and the client.  OK, but this is causing me confusion concerning the SAML subject confirmation method returned by the STS, which as you can see returns holder-of-key:

<saml:SubjectConfirmation>
   <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
   </saml:ConfirmationMethod>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:ns5="http://www.w3.org/2001/XMLSchema-instance"
      ns5:type="KeyInfoType">
      <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
         <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
         <ds:KeyInfo>
            <wsse:SecurityTokenReference
               xmlns:wsse="...oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <wsse:KeyIdentifier
                  ValueType="....X509SubjectKeyIdentifier">xJoy7FOE7FDMYrzbGnZVbz1JfJ4=
               </wsse:KeyIdentifier>
            </wsse:SecurityTokenReference>
         </ds:KeyInfo>
         <xenc:CipherData>
            <xenc:CipherValue>dqTQNjU...encrypted data...8RG0=</xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedKey>
   </ds:KeyInfo>
</saml:SubjectConfirmation>

Question #1:  Does the Metro STS implementation *always* return holder-of-key and *not* sender-vouches?  What if I used a SAMLCallbackHandler to call this STS, would the STS somehow know to use sender-vouches?

Question #2:  If my understanding[1] of holder-of-key is correct, the public key of my SOAP client *must* be inserted within the assertion created by the STS.  But in my example[2] I never supplied the client's public key to the STS so there is no way the STS could have inserted it.  What is the STS inserting then to make this assertion "holder of key"--is this the ephemeral symmetric key that the client creates that you had mentioned earlier that it uses when calling the web service provider?  And, if so, *must* this symmetric key to the STS be the same symmetric key that the client will subsequently use with the web service provider?

Thanks,
Glen

[1] http://www.jroller.com/gmazza/entry/saml_subject_confirmation_methods_holder
[2] http://www.jroller.com/gmazza/entry/metro_and_wstrust
Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
>
>
> metro-3 wrote:
> >
> >> Also, one more question to add to this:  if we are
> >> using message-layer
> >> security and *not* placing the client certificate
> in
> >> the server's
> >> truststore, that implies that the SAML subject
> >> confirmation method must be
> >> holder-of-key and *not* sender-vouches,
> > Yes, in the case that the requester has now
> credential trusted by the
> > server. You have to be holder of key or bearer.
> >
> >> because only
> >> the former has the
> >> client key info necessary for the service to
> properly
> >> encrypt the SOAP
> >> response, correct?
> >
> > See my answer to the your previous post.
> >>
> >
>
> Jiandong, as you explained to me earlier, because of
> the SymmetricBinding
> mechanism it is not necessary for the web service
> provider to have the
> client's public key in order to do message-level
> encryption between it and
> the client.
Even with AsymmetricBinding, you can do this:
put the issued token as <sp:InitiatorToken>, X509 as <sp:RecipientToken> with the Netbin profile:
STS Issued Token with Service Certificate

> OK, but this is causing me confusion
> concerning the SAML
> subject confirmation method returned by the STS,
> which as you can see
> returns holder-of-key:
>
> <saml:SubjectConfirmation>
>
> saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm
> :holder-of-key
>    </saml:ConfirmationMethod>
> <ds:KeyInfo
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>
> mlns:ns5="http://www.w3.org/2001/XMLSchema-instance"
>       ns5:type="KeyInfoType">
> <xenc:EncryptedKey
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
>          <xenc:EncryptionMethod
>
> lgorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mg
> f1p" />
>          <ds:KeyInfo>
>    <wsse:SecurityTokenReference
>
> mlns:wsse="...oasis-200401-wss-wssecurity-secext-1.0.x
> sd">
>                <wsse:KeyIdentifier
>  
> lueType="....X509SubjectKeyIdentifier">xJoy7FOE7FDMYrz
> bGnZVbz1JfJ4=
>                </wsse:KeyIdentifier>
> sse:SecurityTokenReference>
>          </ds:KeyInfo>
> <xenc:CipherData>
>             <xenc:CipherValue>dqTQNjU...encrypted
> </xenc:CipherValue>
>          </xenc:CipherData>
> enc:EncryptedKey>
>    </ds:KeyInfo>
> aml:SubjectConfirmation>
>
> Question #1:  Does the Metro STS implementation
> *always* return
> holder-of-key and *not* sender-vouches?  What if I
> used a
> SAMLCallbackHandler to call this STS, would the STS
> somehow know to use
> sender-vouches?

There are three KeyTypes defined: SymmetricKey, PublicKey, Bearer (no proof key).
We will return holder-of-key for SymmetricKey and PublicKey, and Bearer for Bearer.

Sender-Vouches needs the sender to vouch the SAML assertion, sign it with sender's private which is trusted
by the server. So in concept, it is not a case for use with STS.

>
> Question #2:  If my understanding[1] of holder-of-key
> is correct, the public
> key of my SOAP client *must* be inserted within the
> assertion created by the
> STS.  
if KeyType is SymmetricKey: then an symmetric key is created by STS. It is then encrypted for the service (using the
service certificate) and included in the issued SAML assertion. That is the EncryptedKey you see in the KeyInfo.

>But in my example[2] I never supplied the
> client's public key to the
> STS so there is no way the STS could have inserted
> it.  What is the STS
> inserting then to make this assertion "holder of
> key"--is this the ephemeral
> symmetric key that the client creates that you had
> mentioned earlier that it
> uses when calling the web service provider?  
f KeyType is SymmetricKey: then an symmetric key is created by STS. It is then encrypted for the service (using the
service certificate) and included in the issued SAML assertion. That is the EncryptedKey you see in the KeyInfo.

This key is also passed to the client separately in an RequestedProofKey element in the response from the STS.

If KeyType is public key, the client either pass its certificate or an ephemeral public key in an UseKey element in the RST.
The certificate or the public key is then put into the SAML assertion.

>And, if
> so, *must* this
> symmetric key to the STS be the same symmetric key
> that the client will
> subsequently use with the web service provider?

Yes.

>
> Thanks,
> Glen
>
> [1]
> http://www.jroller.com/gmazza/entry/saml_subject_confi
> rmation_methods_holder
> [2]
> http://www.jroller.com/gmazza/entry/metro_and_wstrust
>
> --
> View this message in context:
> http://old.nabble.com/Question-on-SOAP-client-configur
> ation-for-an-STS-tp28114970p28187070.html
> Sent from the Metro - Users mailing list archive at
> Nabble.com.
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=396204

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question on SOAP client configuration for an STS

metro-3
Check out
http://blogs.sun.com/enterprisetechtips/entry/using_ws_trust_support_in
for details.
[Message sent by forum member 'jdg6688']

http://forums.java.net/jive/thread.jspa?messageID=396205

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]