Hello Guys,
Wanted to update my findings on
the below mentioned issue:
This issue is caused because the
CardSpacePolicyHelper is case sensitive. Look at lines:
The exact lines are:
if (top.equalsIgnoreCase("OBJECT")) {
Iterator iter = om.getChildrenWithName(new QName("PARAM"));
This means that if I have an
object tag with “param” tags than the claims are not included in
the RST and therefore not released by the RP. This will probably require a code
change within that class.
This problem was manifesting in
another place where we were getting privatepersonalidentifier as null. Again
this was because the request for claim was done using <param and not
<PARAM
Thanks,
Daljeet Singh
From: Maken, Dalijeet
Singh (CONSULTANT)
Sent: Wednesday, January 27, 2010 2:41 PM
To: higgins-dev@xxxxxxxxxxx
Subject: Higgins STS and Cloud Selector | Only releasing emailaddress
claim
Hello Guys,
I am running into a strange issue where in the claims
released by the Higgins STS are different (not values but the list) when the
request is submitted from the cloud selector as opposed to submission from
Azigo selector. The scenario is as follows:
-
We have a local instance of the Higgins STS that we
have used to issue a managed card. The card is attached.
-
The card is used in an RP (RPSimple) with azigo as the
card selector. The log of the STS for this request is attached (sts-azigo.out).
As you will see within the logs, the STS is attempting to add all the requested
claims.
-
In the next step the same card is used from the Cloud
Selector (Mode Request 3) with the following request:
<object type="application/x-informationCard"
name="xmlToken">
<param name="privacyUrl"
value="http://wiki.eclipse.org/Cloud_Selector" />
<param name="privacyVersion"
value="1" />
<param name="tokenType"
value="urn:oasis:names:tc:SAML:1.0:assertion" />
<param name="requiredClaims"
value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
</object>
As you will note that we are requesting multiple claim
values, however the STS only looks for the emailaddress and then moves on to
the setDigitalIdentity call, ignoring all the other requested claim values (see
attached log file: sts-cloud-object.out)
Cloud Selector is showing the same behavior in other modes
too and keeps reading the email address claim even when it is not requested.
Will appreciate any inputs on why this might be the case.
Thanks,
Daljeet Singh
This
message w/attachments (message) may be privileged, confidential or proprietary,
and if you are not an intended recipient, please notify the sender, do not use or
share it and delete it. The information contained in this e-mail was obtained
from sources believed to be reliable; however, the accuracy or completeness of
this information is not guaranteed. Unless specifically indicated, this message
is not an offer to sell or a solicitation of any investment products or other
financial product or service, an official confirmation of any transaction, or
an official statement of Merrill Lynch. Subject to applicable law,
Merrill Lynch may monitor, review and retain e-communications (EC) traveling
through its networks/systems. The laws of the country of each sender/recipient
may impact the handling of EC, and EC may be archived, supervised and produced
in countries other than the country in which you are located. This message
cannot be guaranteed to be secure or error-free. References to
"Merrill Lynch" are references to any company in the Merrill Lynch
& Co., Inc. group of companies, which are wholly-owned by Bank of America
Corporation. Securities and Insurance Products: * Are Not FDIC
Insured * Are Not Bank Guaranteed * May Lose Value
* Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or
Activity * Are Not Insured by Any Federal Government Agency. Past
performance is no guarantee of future results. Attachments that are part of
this E-communication may have additional important disclosures and disclaimers,
which you should read. This message is subject to terms available at the
following link: http://www.ml.com/e-communications_terms/.
By messaging with Merrill Lynch you consent to the foregoing.