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)

FYI, there is a simple RP project
(http://dev.eclipse.org/viewsvn/index.cgi/trunk/app/org.eclipse.higgins.rp.simple/?root=Technology_HIGGINS)
available in higgins to handle encrypted and non-encrypted tokens. A
pre-package version of it is available at
http://www.azigo.com/company/dev/higgins-rp/

-Jeesmon

On Thu, Sep 3, 2009 at 8:24 AM, David
Campos<noymn.the.archangel@xxxxxxxxx> wrote:
> 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
>>>> To: Sergey Lyakhov
>>>> Cc: Higgins (Trust Framework) Project developer discussions
>>>> 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
>>
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>


Back to the top