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 <[email protected]>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 <[email protected]> > *To:* Sergey Lyakhov <[email protected]> > *Cc:* Higgins (Trust Framework) Project developer > discussions<[email protected]> > *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 [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
