On 11. nov.2009, at 15:01, Josh Howlett wrote:
>> I'd like to exploit the possibility of implicitly referring
>> to the current user (as things are front-channel), and
>> therefore I am abit stucked because the AttributeQuery
>> extends SubjectQueryAbstractType (if I remember correctly),
>> wher a Subject MUST be included.
>
> IIRC, the response assertion must strongly match the requested subject as well.
Hi Josh! You're right, this is specified in core-3.3.4 - the Subjects MUST strongly match. That said, given the description in 3.3.4 two subjects may apparently strongly match even if a NameID is not included in one and is included in the other.
>
>> Would it be a good idea to omit the NameID, and use
>> Subjectconf as sender-vouces or bearer... Something like
>> this? Better ideas appreciated....
>
> How about defining a new NameID which takes no value, but whose presence in the request indicates that the SAML Issuer must return a statement within the assertion which takes a value that names the subject of the enveloping assertion. It's fairly ugly, but...
I'm not sure if I follow completely... But if you take a closer look at my example, it is a schema-valid request with a subject without NameID at all. And at the same time, I think, it may be considered to strongly match the subject included in the response.
Andreas
