Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Re: Question about ICardProtocolHandler code (Token decryption)
Hi Markus,

Thanks for that great explanation about how works the "AppliesTo" attribute. I had been looking forward a proper explanation long time ago but never managed to understand it :) Now I know it.

Thanks both of you for your help in this matter. Now I'll have to modify properly the RP and have a look on the IdP in order to work properly with the appliesTo.

Thanks,
---
David Campos
Safelayer Secure Communications S.L.
DMAG UPC Researcher


On Thu, Sep 3, 2009 at 13:31, Markus Sabadello <markus.sabadello@xxxxxxxxx> wrote:
Hi David,

How are you :)

No. It's like this:

P-Card Auth ---> through SSL ---> encrypted token by CardSelector
P-Card Auth ---> no SSL ---> clear token
M-Card Auth with appliesTo ---> through SSL ---> encrypted token by IdP
M-Card Auth with appliesTo ---> no SSL ---> clear token
M-Card Auth without appliesTo ---> through SSL ---> encrypted token by CardSelector

M-Card Auth without appliesTo ---> no SSL ---> clear token

In other words:
The token is only encrypted if it's POSTed through SSL.
And who encrypts the token depends on whether an AppliesTo element is sent in the RST to the IdP, which in turn depends on the presence of the ic:RequireAppliesTo element in the card definition (.crd file).

If the ic:RequireAppliesTo element exists, then the M-Card is a so-called "Auditing Card", and the RST to the IdP contains an AppliesTo element, like Sergey said. This AppliesTo element contains the target URL and the certificate (if SSL) of the RP. Therefore the IdP encrypts the token and returns it to the Selector, which just hands it through to the RP. "Auditing Cards" are the exception and only used if there are good reasons.

If the ic:RequireAppliesTo doesn't exist, then the M-Card is just a normal M-Card, and the RST to the IdP contains no AppliesTo element. Then the IdP returns a clear token (because - as you said in your original assumption - there is no direct interaction between IdP and RP). In this case the Selector encrypts the token before posting it to the RP

To be precise, when I say that the Selector encrypts the token, then in the Higgins architecture this sometimes means that it's actually the I-Card Service which encrypts it, because some Selectors "outsource" a lot of functionality to the I-Card Service. But this is completely transparent and something only Selector developers have to care about.

From the RP's point of view, it's all the same:
If you have an https URL you always get an encrypted token, and if you have an http URL you always get a clear token. You don't really have to care about who encrypts it.

There could be rare exceptions to this if you using an "Auditing Card". Sometimes the IdP could return an encrypted token even if it's POSTed to http (not https), because the IdP could have a pre-existing relationship with the RP and somehow already know its certificate. But I don't know of any IdP that does this.

To make your code work, basically you need to make it so that you only call DecryptElement() if your token is encrypted. And since you are the RP, you must know to which URL the token got POSTed, which means you also know already if it's encrypted or not (encrypted if https, not encrypted if http).

Note that all the above only concerns encryption. Tokens are still always signed.

See sections 3.3 and 11.7 of http://docs.oasis-open.org/imi/identity/v1.0/identity.pdf
for more info on AppliesTo and RequireAppliesTo.

Markus

On Thu, Sep 3, 2009 at 12:53 PM, David Campos <noymn.the.archangel@xxxxxxxxx> wrote:
I see... Finally I understood the meaning of the "AppliesTo" param :)

Thanks for resolving my doubt Sergey. Anyway, since that line is not into a conditional sentence, Higgins IdP always have to send an encrypted token to Higgins RP, otherwise that line of code would fail saying that the token can't be decrypted, wouldn't it?

I haven't tested it, it's all guesswork, but, if I remember well, somebody had recently problems with that line and his problem was that he was doing a non-SSL authentication. I remember that somebody said that Sample-RP was only expecting SSL-authentications (so probably encrypted tokens). Could you confirm me if the following scenarios are right?

P-Card Auth ---> though SSL ---> encrypted token by CardSelector
P-Card Auth ---> no SSL ---> encrypted token by CardSelector
M-Card Auth with appliesTo ---> though SSL ---> encrypted token by IdP
M-Card Auth with appliesTo ---> no SSL ---> encrypted token by IdP
M-Card Auth without appliesTo ---> though SSL ---> clear token
M-Card Auth without appliesTo ---> no SSL ---> clear token

Am I right? Thanks for your help,

---
David Campos
Safelayer Secure Communications S.L.
DMAG UPC Researcher

On Thu, Sep 3, 2009 at 12:42, Sergey Lyakhov <slyakhov@xxxxxxxxxxxxxx> wrote:
David,
 
> My question is... when is the token ciphered? Who ciphers it? CardSpace?
> I don't think that the IdP is able to cipher the token after generation, mainly because there should not
> be any direct interaction between IdP and RP so IdP is unable to get RP public key.
 
In case of p-card, token is encrypted by selector.
In case of m-card, selector may send RP certificate to IdP as part of AppliesTo information in RST message. So, IdP encrypts a token if AppliesTo contains a certificate.
 
Thanks,
Sergey Lyakhov
----- Original Message -----
From: David Campos
Sent: Wednesday, September 02, 2009 5:11 PM
Subject: Question about ICardProtocolHandler code (Token decryption)

Hi Sergey,
I have been looking though your RP code in order to find where the token is verified and claims are extracted. I've found that the token first is decrypted with a private key (obtained through the keystore) and afterwards verified.
My question is... when is the token ciphered? Who ciphers it? CardSpace?
I don't think that the IdP is able to cipher the token after generation, mainly because there should not be any direct interaction between IdP and RP so IdP is unable to get RP public key. The only solution that comes to my mind is that CardSpace recieves a clear token through an SSL channel and afterwards it ciphers it with the RP SSL public key, but this scenario does not seem really logical to me since the comunication is always covered with the SSL layer.
Could you please enlight me about what is decrypted and why in the following instruction?
  log.info("Decrypt token using key " + key + " key algorithm " + key.getAlgorithm());
  ie = secext.DecryptElement(elemToken, (PrivateKey)(keyStore.getKey(keyStoreAlias,keyStorePwd.toCharArray())));
  log.info("Decrypted token looks like\n"+ie.getAs(java.lang.String.class));

If it does help you, is the line 146 of ICardProtocolHandler that is found inside org.eclipse.higgins.rp.icard package.
Thank you for the help.
Regards,
---
David Campos
Safelayer Secure Communications S.L.
DMAG UPC Researcher


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top