Jim
Major
1. Do we have any other examples where we might have a SAML
requester/responder other than the case of the RP/IdP? If so, it
might be wise to mention at least one other case in the introductory
paragraph in section 1. Otherwise it might be easier to just say that
we are sending messages between the RP and the IdP and not generalize
it. Can anybody see a reason that one might want to reverse the
endpoints? So that the RP becomes the server and the IdP the client???
2. In section 3, I would suggest adding the text "There MUST be at
most one SAML-Message Attribute in either a RADIUS request or response
message."
It is almost impossible to fit a entire SAML message into a single SAML-
Message attribute (253 bytes), so almost always there will be more than on
SAML-Message attribute in both, RADIUS requests and responses when
transporting SAML data. All these attributes are part of the same extended
fragmented attribute, but section 3 is talking about the basic RADIUS
attribute. Note that this draft has not yet adopted extended attributes
format.
If your intention was to suggest that no more than 1 SAML Message MUST
be included per RADIUS packet, I'm not sure to agree either. At least, I
do not
see a clear motivation for such limitation.
My intent was to say that there was at most one SAML Assertion in a RADIUS
request or response message. If this is not true then we need to find a way
to say that assertion #1 has ended and we are now dealing with assertion #2.
Extended attributes already deal with this situation thanks to the M
flag. Last fragment of an attribute is not marked with M flag. Hence you
know when SAML message #1 ends, and thus a different one starts if you
find another SAML-Message attribute. that
IMO this is not required. EAP is meant to provide authentication, while
SAML is intended to provide authorization. A principal may be succesfuly
authenticated, but fail to obtain authorization information. One process
should not interfere in the other. Think that a RP may not issue the
AuthnReq. Besides, if the RADIUS server and the IdP are not collocated,
I do not think it is a good idea to trick the EAP stack in the RADIUS
server to force an EAP failure if the IdP replies with an SAML error.
Allowing for different answers makes more sense if the flow changes as
above. Otherwise I don't see that this is necessarily true. We have
already stated that the AuthnRequest can and should in some cases affect how
the EAP is performed. Are you talking about failing because you are not
going to return some attributes or because you are going to say that yes I
know who they are, but they are not supposed to talk to you. In this case
ABFAB has already said you are supposed to fail the EAP conversation as
well. Under what circumstances do you think this would occur.
I think this has already been solved by Sam in a previous message.
Regards,
Alejandro
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
