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 <[email protected]>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 < > [email protected]> 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 <[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 >> >> > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
