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