SAML support for freeRadius

Stefan Winter stefan.winter at restena.lu
Tue Mar 3 07:49:14 CET 2009


Hi,

> Scenario 2 & 3 are close to my task.
> Let me explain my scenario.
> User identities are loacted in a SAML-enabled id store.
> User requests are directed to a proxy. Proxy should authenticate the
> user against the configured freeRaduis server. freeRadius server
> should validate it against the SAML-enabled server.
> Depending on the response from SAML-enabled server, radius server
> accepts/rejects the user.
You didn't specify in your (private! - please stick to the mailing list)
reply what kind of credential the user sends in the request. Is it a
password? Then we're talking about scenario 2. In which case the sad
answer for you is:

Sorry, this is not how SAML works. SAML doesn't transport or validate
credentials. It transports assertions being made about an authentication
which happened out-of-band. I.e. a SAML auth request is basically the
question "Do you know if this user has succesfully authenticated to you
by whatever means you used for authentication?" And the SAML response is
"Yes, I know that guy. He's alright.". No passwords involved in this
communication.
So your user's password needs to be validated *somehow* - but not inline
in SAML. You can see that in popular SAML implementations where the
actual credentials are stored in $WHATEVER - quite often an
LDAP/ActiveDirectory store. Authentication then happens by a user
visiting the IdP's web site, entering his password there (HTTP - no SAML
involved) which is then validated against that LDAP store. *Then* the
IdP constructs a SAML authentication assertion *about* the
authentication that just happened.
In short, feeding a password into FreeRADIUS and then magically doing
SAML doesn't exist. All hope is not lost, however. You can tap with
FreeRADIUS onto the same backend that's also used by SAML. FreeRADIUS
merrily uses LDAP stores to validate user logins.

If, OTOH, the user is not supposed to send a password but rather a SAML
artifact to prove that it authenticated before, and FreeRADIUS should
accept the user based on him presenting the assertion, then we're
talking business. In that case though, the equally sad answer is that
there is no defined transport to send SAML within RADIUS. What you'd
need then is a means to send SAML payloads in RADIUS attributes. The
most logical way of doing so would be some kind of "EAP-SAML" - but such
a thing doesn't exist as an IETF standard today. So if authenticating
via SAML assertions is something you want to do - please present your
use case loudly to IETF people - they might listen and get going :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473




More information about the Freeradius-Users mailing list