locked
How does the client/Browser submit the issued token to RP?

    Question

  • Hi guys,

    When I read the Information Card Profile v1.0, I've found that there is no description about how the client / Browser submit the issued token at the final step.
    What I want to know is how is the message looks like? Is there only the security token or there are also other information comes together with the token? Will the message also be secured with transport binding or symmetric binding like the RST and RSTR message in the case that a relying party is a webservice?

    Where can I find some specification for it or there is no such document?


    cheers

    Xuan
    Thursday, February 21, 2008 4:13 PM

Answers

  • To clarify things a bit..

    For Browser, only the token is the thing available. There is no proof key involved (KeyType=NoProofKey). There is no "message exchange" for the web site. Though there may be messages exchanged with the resource STS (if present in scenario).

     

    Later Xuan clarified the intent as non-browser scenario. Here, the client program (maybe using WCF) asks for a CardSpace token. The question is what all does Client program do to use the token properly, like using the proof token.

    Is this the correct summary of question?

     

    For above question, the following will help to understand what is happening.

     

    If the client uses WCF:

    Assume a calculator client and a calculator service which offers an "Add" service operation. The client does not explicitly invoke CardSpace. The WCF stack on client looks at service's policy ( available via app.config or some other way) and determines that service requires a CardSpace token. The stack calls the GetToken and gets the token alongwith the handle to the proof key. The stack then creates the secure "Add" message by embedding the token, signing with the proof key, encrypting to service, etc. So the client stack uses the proof key. The client code simply created the vanilla "Add" operation request message.

    The "things" that the WCF stack on client does is controlled by the binding options. For e.g. if SecureConversation is enabled on the binding, then WCF will perform SecureConversationToken negotiation.

     

    Now when service receives the "Add" message, the WCF stack (or other WS-* compatible stack) on service side decrypts the message, verifies signature of proof key, validates token and finally passes the "Add" operation data to the service. The actual service code usually will do more with the token (like mapping to a user, validating issuer, etc) and perform the Add operation and return the message.

     

    If the client is non-WCF:

    Assume a native client written in C++ where no WS-* based stack available. This client is talking to a custom socket server application which needs a cardspace token and wants to do proof key related validations. How client gets hold of this "policy" is unknown (maybe baked into the application itself). Then, it is the client code responsibility to do all the operations that WCF stack was doing in the previous explanation. So for e.g. the client would:

    - Call GetToken explicitly

    - Get hold of CryptoHandle for the proof key.

    - Create a "response" to the server having following characteristics (though it finally depends upon the communication pattern defined between client/server):

    1. Response has the token (which contains the proof key)

    2. Some challenge data is signed/encrypted using proof key

    3. Application specific data

    4. Additional security data like timestamps, session key negotiation (using the cardspace token to bootstrap the process), etc,

    - Secure the response to server by encrypting it (or relying on the transport). Most likely, client has public key of server so can encrypt the response for it (or use the session key).

     

     

    Hope this helps,

    Rakesh

    Saturday, February 23, 2008 3:26 AM

All replies

  • There is a CardSpace sample on how to deal with the returned security token.  You can find it here:

     

    http://msdn2.microsoft.com/en-us/library/aa967562.aspx

     

     

    Let me know if you have further questions.

     

    Thursday, February 21, 2008 6:20 PM
  • Well actually there's a very good reason there's no documentation; it could be anything.

    The format of the token you get back depends on the format you asked for; for self issued cards you can only get SAML tokens back; but Information Card is token agnostic, it can carry anything, for example the OpenID folks are working on their own token format.

    The SAML documentation is at http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

    But the selector will only pass on the token, nothing more.


    Thursday, February 21, 2008 7:32 PM
  • Brian, thanks for your reply, but I'm afraid that's not exactly what I want.
    What I want to know is if there is any rule for a client to follow when it submit the security token to the relying party. But thanks any way.

    Xuan
    Thursday, February 21, 2008 10:16 PM
  •  Xuan Chen wrote:
    Brian, thanks for your reply, but I'm afraid that's not exactly what I want.
    What I want to know is if there is any rule for a client to follow when it submit the security token to the relying party. But thanks any way.

    Xuan


    Ah you mean acting as a selector? There's the selector interop documentation. But basically it's strip out everything from the RSTR but the token, then forward.
    Thursday, February 21, 2008 10:19 PM
  • blowdart,

    What should be contained in the message which a client application sent to the relying party? Certainly, there must be a issued security token(and in any format if I have understood you correctly). But anything else? And how will the message be secured? Or it all depends on the relying party's policy?

    I am writing my thesis about CardSpace and I should describe the whole protocol detailly and correctly. For the other messages, i.e. RST and RSTR, the CardSpace specification defines what can or must be contained in the message but for the message from client to relying party, I haven't found any. So I just guess the message must contain the security token and anything else that the relying party requires and the message can also be secured in any way that the relying party defines. But I'm not absolutly sure about it.

    cheers

    Xuan
    Thursday, February 21, 2008 10:35 PM
  •  blowdart wrote:
     Xuan Chen wrote:
    Brian, thanks for your reply, but I'm afraid that's not exactly what I want.
    What I want to know is if there is any rule for a client to follow when it submit the security token to the relying party. But thanks any way.

    Xuan


    Ah you mean acting as a selector? There's the selector interop documentation. But basically it's strip out everything from the RSTR but the token, then forward.


    No, I don't mean the selector but the client program which calls the selector to retrieve a security token from the identity provider and finally submit the token to the relying party to authenticate to it.





    Thursday, February 21, 2008 10:38 PM
  • Just the token, nothing more, which can be in any format. What else do you think the relying party needs/defines a need for? Security is down to the RP; although of course generally you want to match the encryption a selector uses. Funnily enough I blogged about that a couple of days back.

    I'd suggest reading the selector interop spec and starting from there.
    Thursday, February 21, 2008 10:38 PM
  •  Xuan Chen wrote:


    No, I don't mean the selector but the client program which calls the selector to retrieve a security token from the identity provider and finally submit the token to the relying party to authenticate to it.



    Umm that *is* a selector really. Or I guess the browser in most scenarios; but the selector just puts the token into the html form and the browser submits it. Just the token. Nothing more.
    Thursday, February 21, 2008 10:40 PM
  •  blowdart wrote:
     Xuan Chen wrote:


    No, I don't mean the selector but the client program which calls the selector to retrieve a security token from the identity provider and finally submit the token to the relying party to authenticate to it.



    Umm that *is* a selector really. Or I guess the browser in most scenarios; but the selector just puts the token into the html form and the browser submits it. Just the token. Nothing more.


    Ok, firstly I mean for the client / server application senario not for the browser / website senario. Sorry that I haven't described it clearly in my post.

    Now back to my question. If the client only submits the token to the relying party and nothing else, it really confuses me how will the proof key be used? Shouldn't the client use the proof key to sign some message and prove the ownship of the token to the relying party?

    Thursday, February 21, 2008 10:53 PM
  •  blowdart wrote:
    Just the token, nothing more, which can be in any format. What else do you think the relying party needs/defines a need for? Security is down to the RP; although of course generally you want to match the encryption a selector uses. Funnily enough I blogged about that a couple of days back.

    I'd suggest reading the selector interop spec and starting from there.


    The selector interop spec you mentioned is what I called CardSpace specification in my post.
    I've already read it. thanks for your tip.
    Thursday, February 21, 2008 10:57 PM
  • Ah ok, you're into WS-Trust scenarios now; proof cards are part of that, not part of Information Cards. You're read Vittorio's blog entry on it?

    I must admit it's on my todo list right now; so I haven't actually messed around with proof keys in any way so far, there has been no real need.

    (Darn it, something for sharpSTS 1.1 I guess)
    Thursday, February 21, 2008 11:07 PM
  • Ok, I see what you mean now.  You want better documentation on what to expect when you make the actual GetToken call (http://msdn2.microsoft.com/en-us/library/aa702725.aspx).

     

    Unfortunately I don't believe there is much available documentation on this, beyond what you see on the MSDN page.

    Thursday, February 21, 2008 11:24 PM
  •  blowdart wrote:
    Ah ok, you're into WS-Trust scenarios now; proof cards are part of that, not part of Information Cards. You're read Vittorio's blog entry on it?

    I must admit it's on my todo list right now; so I haven't actually messed around with proof keys in any way so far, there has been no real need.

    (Darn it, something for sharpSTS 1.1 I guess)


    Yes, I've read Vittorio's blog about proof key, it explains the whole concept of proof key pretty clearly.
    About WS-Trust....I remember it is about how the requesting and returning a security token right? That's exactly the transaction between selector and STS. It does defines how to generate the proof key, but doesn't describe how to use it.
    I don't think the transaction between the client and relying party is also a WS-Trust scenario, because there is no need for a client requesting a token from the relying party. The client only submit the token to relying party and does some proof-of-possession works with the proof key.

    And the final message I guess is something like this:

    Secure{security token, message, Signature over the message using the proof key}

    • the Secure which wraps the whole information can be any method that the relying party defines, i.e. HTTPS, SOAP message security, etc.
    • the security token is the issued security token which comes from the identity provider. 
    • the message again can be any message that a relying party requires, i.e. a timestamp, a SQL query which asks for some information in the web service, or a shopping order, etc.
    • and finally a signature which is signed using the proof key over the message to prove the ownership of the the security token
    This is just my opinion but I can't find any document to prove it. What do you think about it?

    Friday, February 22, 2008 12:08 AM
  •  Brian Houck wrote:

    Ok, I see what you mean now.  You want better documentation on what to expect when you make the actual GetToken call (http://msdn2.microsoft.com/en-us/library/aa702725.aspx).

     

    Unfortunately I don't believe there is much available documentation on this, beyond what you see on the MSDN page.



    Hi, Brian

    The link looks quite useful for me. But what a shame that there is no more documentation about it.
    Friday, February 22, 2008 12:21 AM
  •  Xuan Chen wrote:


    And the final message I guess is something like this:

    Secure{security token, message, Signature over the message using the proof key}

    • the Secure which wraps the whole information can be any method that the relying party defines, i.e. HTTPS, SOAP message security, etc.
    • the security token is the issued security token which comes from the identity provider. 
    • the message again can be any message that a relying party requires, i.e. a timestamp, a SQL query which asks for some information in the web service, or a shopping order, etc.
    • and finally a signature which is signed using the proof key over the message to prove the ownership of the the security token
    This is just my opinion but I can't find any document to prove it. What do you think about it?



    Well this is the thing; it's only a transport mechanism. Once the token is generated it's out of CardSpace's hands (unless you're sending it to a selector, in which case the behaviour is specified). CardSpace doesn't care what happens with the token, or how you use proof keys you specify, in the same way it doesn't care about the format of the token itself, or indeed the encryption used (or not as the case may be)
    Friday, February 22, 2008 8:17 AM
  •  Xuan Chen wrote:


    I am writing my thesis about CardSpace


    BTW if you feel an STS would help you drop me an email; in a couple of weeks SharpSTS should be done, and I can punt you the code and try to help you set it up.
    Friday, February 22, 2008 8:19 AM
  • To clarify things a bit..

    For Browser, only the token is the thing available. There is no proof key involved (KeyType=NoProofKey). There is no "message exchange" for the web site. Though there may be messages exchanged with the resource STS (if present in scenario).

     

    Later Xuan clarified the intent as non-browser scenario. Here, the client program (maybe using WCF) asks for a CardSpace token. The question is what all does Client program do to use the token properly, like using the proof token.

    Is this the correct summary of question?

     

    For above question, the following will help to understand what is happening.

     

    If the client uses WCF:

    Assume a calculator client and a calculator service which offers an "Add" service operation. The client does not explicitly invoke CardSpace. The WCF stack on client looks at service's policy ( available via app.config or some other way) and determines that service requires a CardSpace token. The stack calls the GetToken and gets the token alongwith the handle to the proof key. The stack then creates the secure "Add" message by embedding the token, signing with the proof key, encrypting to service, etc. So the client stack uses the proof key. The client code simply created the vanilla "Add" operation request message.

    The "things" that the WCF stack on client does is controlled by the binding options. For e.g. if SecureConversation is enabled on the binding, then WCF will perform SecureConversationToken negotiation.

     

    Now when service receives the "Add" message, the WCF stack (or other WS-* compatible stack) on service side decrypts the message, verifies signature of proof key, validates token and finally passes the "Add" operation data to the service. The actual service code usually will do more with the token (like mapping to a user, validating issuer, etc) and perform the Add operation and return the message.

     

    If the client is non-WCF:

    Assume a native client written in C++ where no WS-* based stack available. This client is talking to a custom socket server application which needs a cardspace token and wants to do proof key related validations. How client gets hold of this "policy" is unknown (maybe baked into the application itself). Then, it is the client code responsibility to do all the operations that WCF stack was doing in the previous explanation. So for e.g. the client would:

    - Call GetToken explicitly

    - Get hold of CryptoHandle for the proof key.

    - Create a "response" to the server having following characteristics (though it finally depends upon the communication pattern defined between client/server):

    1. Response has the token (which contains the proof key)

    2. Some challenge data is signed/encrypted using proof key

    3. Application specific data

    4. Additional security data like timestamps, session key negotiation (using the cardspace token to bootstrap the process), etc,

    - Secure the response to server by encrypting it (or relying on the transport). Most likely, client has public key of server so can encrypt the response for it (or use the session key).

     

     

    Hope this helps,

    Rakesh

    Saturday, February 23, 2008 3:26 AM
  •  blowdart wrote:
     Xuan Chen wrote:


    I am writing my thesis about CardSpace


    BTW if you feel an STS would help you drop me an email; in a couple of weeks SharpSTS should be done, and I can punt you the code and try to help you set it up.


    I appreciate for your kind help! It would be certainly very helpful to me. Please contact me with this E-Mail:  xuan.chen.china@gmail.com if you have done the SharpSTS project.
    Thursday, February 28, 2008 12:22 AM
  •  Rakesh Bilaney - MSFT wrote:

    To clarify things a bit..

    For Browser, only the token is the thing available. There is no proof key involved (KeyType=NoProofKey). There is no "message exchange" for the web site. Though there may be messages exchanged with the resource STS (if present in scenario).

     

    Later Xuan clarified the intent as non-browser scenario. Here, the client program (maybe using WCF) asks for a CardSpace token. The question is what all does Client program do to use the token properly, like using the proof token.

    Is this the correct summary of question?

     

    For above question, the following will help to understand what is happening.

     

    If the client uses WCF:

    Assume a calculator client and a calculator service which offers an "Add" service operation. The client does not explicitly invoke CardSpace. The WCF stack on client looks at service's policy ( available via app.config or some other way) and determines that service requires a CardSpace token. The stack calls the GetToken and gets the token alongwith the handle to the proof key. The stack then creates the secure "Add" message by embedding the token, signing with the proof key, encrypting to service, etc. So the client stack uses the proof key. The client code simply created the vanilla "Add" operation request message.

    The "things" that the WCF stack on client does is controlled by the binding options. For e.g. if SecureConversation is enabled on the binding, then WCF will perform SecureConversationToken negotiation.

     

    Now when service receives the "Add" message, the WCF stack (or other WS-* compatible stack) on service side decrypts the message, verifies signature of proof key, validates token and finally passes the "Add" operation data to the service. The actual service code usually will do more with the token (like mapping to a user, validating issuer, etc) and perform the Add operation and return the message.

     

    If the client is non-WCF:

    Assume a native client written in C++ where no WS-* based stack available. This client is talking to a custom socket server application which needs a cardspace token and wants to do proof key related validations. How client gets hold of this "policy" is unknown (maybe baked into the application itself). Then, it is the client code responsibility to do all the operations that WCF stack was doing in the previous explanation. So for e.g. the client would:

    - Call GetToken explicitly

    - Get hold of CryptoHandle for the proof key.

    - Create a "response" to the server having following characteristics (though it finally depends upon the communication pattern defined between client/server):

    1. Response has the token (which contains the proof key)

    2. Some challenge data is signed/encrypted using proof key

    3. Application specific data

    4. Additional security data like timestamps, session key negotiation (using the cardspace token to bootstrap the process), etc,

    - Secure the response to server by encrypting it (or relying on the transport). Most likely, client has public key of server so can encrypt the response for it (or use the session key).

     

     

    Hope this helps,

    Rakesh



    More clearly could it not be explained!! That's exactly what I want to have. Thanks a million!! It is really great help to me!!

    cheers

    Xuan
    Thursday, February 28, 2008 12:25 AM