El 28/11/11 14:45, Alan DeKok escribió:
Alejandro Perez Mendez wrote:
How do you tie the packets together?
As you say below, the State attribute would do the work. Additionally,
the "more SAML data" could contain a reference, and be included in the
following Access-Request message. Though I think the State attribute
would be enough.
It would be preferable, but not enough. The packet needs to be routed
through a proxy chain, so it needs to contain a User-Name attribute.
you are right. I was just assuming that the User-Name was already there.
- user authenticates
- final Access-Accept contains a State attribute
- final Access-Accept contains an attribute "more SAML data"
-final Access-Accept contains a Termination-Action attribute with the
value of RADIUS-Request
I'm not sure I'd do that. Termination-Action is for *terminating* the
service. In your use-case, service would continue, but more SAML
authorization attributes would be needed.
RFC says, in regard with the State attribute:
This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client
to the server in the new Access-Request reply to that challenge,
if any.
This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request.
So I understood that if State attribute is sent within an
Access-Request, then Termination-Action is required.
Instead, the first Access-Accept could contain "Service-Type =
Additional-Authorization". This would be a new value indicating that
additional authorization is required for the user.
But then it is required to define a new Service-Type value. Service-Type
is not mandatory, would it be better to just not including it in the
first Access-Accept? The "more SAML data" should be enough to indicate that.
Regards,
Alejandro
The NAS would then send requests for more data, as discussed earlier.
The final Access-Accept would contain an updated Service-Type, for the
users real service.
Another alternative would be the following: after the "more SAML data"
attribute is sent, instead of performing several
Access-Request/Access-Challenge roundtrips, perform several
Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if
this procedure would go against something in the standards.
I think using Access-Challenge would be better.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
