SimpleSAML with Radius
Justin
I'm trying to set up SimpleSAMLphp for Google Apps Edu authenticating
against a Radius server. I've followed the documentation for both
setting up radius AND setting up SimpleSAMLphp as an idP for Google,
however when I try to test logging in, all I see is a blank page.
So I have two questions.
1) What is causing this blank page/what is needed to try and
troubleshoot it? I've looked at the log file, and it looks like
SimpleSAMLphp is trying to use LDAP, even though I've disabled the
LDAP module itself, and there is no ldap info in the authsources
info...
2) How does google know which user is logging in? My Radius usernames
are not quite the same as users' Google Apps usernames. Does this need
to be included in some sort of radius attribute? If so, what should it
look like?
Regards,
Justin
Justin
On Apr 8, 10:11 am, Justin <althalu...@gmail.com> wrote:
> Hi,
>
> I'm trying to set up SimpleSAMLphp for Google Apps Edu authenticating
> against a Radius server. I've followed the documentation for both
> setting up radius AND setting up SimpleSAMLphp as an idP for Google,
> however when I try to test logging in, all I see is a blank page.
>
> So I have two questions.
>
> 1) What is causing this blank page/what is needed to try and
> troubleshoot it? I've looked at the log file, and it looks like
> SimpleSAMLphp is trying to use LDAP, even though I've disabled the
> LDAP module itself, and there is no ldap info in the authsources
> info...
login-radius.php
>
> 2) How does google know which user is logging in? My Radius usernames
> are not quite the same as users' Google Apps usernames. Does this need
> to be included in some sort of radius attribute? If so, what should it
> look like?
>
username, but the login username for radius is different to the
username for Google. I still need to know how I can get SimpleSAML to
send the correct login names? I would guess I'd need to somehow define
a custom radius attribute and map it to something in SimpleSAML? How
would I do that?
Justin
> I still need some help here. Google obviously needs to be given a
> username, but the login username for radius is different to the
> username for Google. I still need to know how I can get SimpleSAML to
> send the correct login names? I would guess I'd need to somehow define
> a custom radius attribute and map it to something in SimpleSAML? How
> would I do that?
"User-Name" attributes and store it in $attributes to fix my username
problem. It's working, but is there a better way?
Stefan Winter
> I played with the code for auth/login-radius.php and made it accept
> "User-Name" attributes and store it in $attributes to fix my username
> problem. It's working, but is there a better way?
>
No need to play with code. You can transport custom/supplementary AAI
attributes in Vendor-Specific RADIUS attributes just fine. In config.php:
* vendor and vendor-attr below indicate in which RADIUS
attribute the AAI attributes are in.
* multiple occurences of that RADIUS attribute are supported
In the example given in the config.php template, the following is set:
'auth.radius.vendor' => '23735',
'auth.radius.vendor-attr' => '4',
In this example, the AAI attributes are extracted from the
Vendor-Specific attribute from Vendor 23735 (which happens to be my
company :-) ), in attribute number 4.
I guess this could be documented a bit more clearly. The implicit
assumptions associated with this config option are:
- The attribute denoted here is a "string" type attribute
- content is expected to be of the for "attribute-type=attribute-value"
Note: If you *just* need the one attribute User-Name converted into a
specific AAI attribute (and I think that's sufficient for Google), then
the line
'auth.radius.URNForUsername' =>
'urn:mace:dir:attribute-def:eduPersonPrincipalName',
is your friend: the content of the RADIUS User-Name attribute is the
value of the attribute in this config line. So, if Google expects you to
send your user name in an attribute "google-full-name", then you could
set this config option to
'auth.radius.URNForUsername' => 'google-full-name'
and you're done.
HTH,
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
Stefan Winter
> I guess this could be documented a bit more clearly. The implicit
> assumptions associated with this config option are:
>
> - The attribute denoted here is a "string" type attribute
> - content is expected to be of the for "attribute-type=attribute-value"
>
Right. I must have written this piece of documentation in write-only
mode. If I had read my own stuff, I could have read:
* user attributes are expected to be stored in a Vendor-Specific RADIUS
string attribute and have
* the form aai-attribute=value
I.e. it is already documented in config.php. I need more coffee before I
write e-mail.
Stefan
Justin Steward
Thanks for your reply.
Hi again,
Right. I must have written this piece of documentation in write-only
> I guess this could be documented a bit more clearly. The implicit
> assumptions associated with this config option are:
>
> - The attribute denoted here is a "string" type attribute
> - content is expected to be of the for "attribute-type=attribute-value"
>
mode. If I had read my own stuff, I could have read:
* user attributes are expected to be stored in a Vendor-Specific RADIUS
string attribute and have
* the form aai-attribute=value
I.e. it is already documented in config.php. I need more coffee before I
write e-mail.
Can you shed any light there, or point me to some documentation on the matter that actually makes sense?
~Justin
Stefan Winter
> Unfortunately I have no understanding of how the Vendor-Specific
> attributes work, and every attempt I made at it just returned a string
> of hexadecimal characters that seemed more or less useless.
>
> Can you shed any light there, or point me to some documentation on the
> matter that actually makes sense?
Oh. Vendor-Specific attributes are a concept of RADIUS, defined in the
base RFC 2865. In short: there are only 256 "IETF standard" attributes
for RADIUS. There are thousands of companies though that think they need
to convey their own stuff in RADIUS. Conveying AAI attributes is one of
the things for which no IETF standard attribute is foreseen.
The IETF solution: there is one "special" attribute, number 26: instead
of having direct content (string/integer/...) the content of this
attribute starts with an integer denoting the "vendor" who defined
what's coming afterwards. That vendor can define it's own attributes,
and they contain whatever "stuff" the vendor thinks is appropriate - and
in the AAI attributes case, "stuff" would be a string of the form
"aai-attribute=value".
So much for the concept. Are you using FreeRADIUS? I can give you a
short walk-through how to implement VSAs (Vendor-Specific Attributes) to
convey your data.
Stefan
Stefan Winter
> just returned a string of hexadecimal characters that seemed more or
> less useless.
In your IdP, did you set
'base64attributes' => ...
If yes, to what? Try inverting it. It may be that the IdP gets the
attributes just fine, but sens them on in base64 encoding. You would see
hexadecimal gibberish as you write here...
Stefan
Justin Steward
Hi,
In your IdP, did you set
> just returned a string of hexadecimal characters that seemed more or
> less useless.
'base64attributes' => ...
If yes, to what? Try inverting it. It may be that the IdP gets the
attributes just fine, but sens them on in base64 encoding. You would see
hexadecimal gibberish as you write here...
Yes, I am using freeradius. A guide on how to implement those AAI attributes would be very welcome.
Many Thanks,
Justin
Stefan Winter
> Sorry, guess I wasn't clear enough there. I was seeing a hexadecimal
> string when using the radtest command just to ensure that the radius
> server was indeed sending back the data I expected it to. This wasn't
> in SimpleSAMLphp at all.
Okay.
> Yes, I am using freeradius. A guide on how to implement those AAI
> attributes would be very welcome.
Okay:
Attributes for FreeRADIUS are defined in "dictionaries" which map
between the integers of vendors and attribute numbers to more easily
usable words. In raddb/dictionary, add for example the following:
# --- begin RESTENA AAI VSA ---
VENDOR RESTENA 23735
BEGIN-VENDOR RESTENA
ATTRIBUTE RESTENA-AAI-Attribute 4 string
END-VENDOR RESTENA
# --- end RESTENA AAI VSA ---
From now on, you have a string-type attribute called
"RESTENA-AAI-Attribute" (attribute number 4 in the RESTENA space). Note:
the format for dictionary entries changed between FreeRADIUS 2.1.3 and
2.1.4 - see other dictionary files from older versions for the old
syntax. You can add values to the replies with the += attribute:
RESTENA-AAI-Attribute += "firstname=Foo"
RESTENA-AAI-Attribute += "lastname=Bar"
for a given user, just like you would add any other attribute. NOTE
WELL: Vendor 23735 is RESTENA. That's not perfect for you. In order of
preference:
1) If your company has an own IANA Private Enterprise Number, you should
use that and define your own attribute.
- OR -
2) If your company does not have one, you can apply for one here:
http://pen.iana.org/pen/PenApplication.page
- OR -
3) You could ignore it and use our PEN
- OR, ONLY IF YOU REALLY REALLY KNOW WHAT YOU ARE DOING -
4) You can use any number you want. PLEASE NOTE: you are breaking
internet standards. Make sure that such attributes will NEVER leave your
closed RADIUS infrastructure, i.e. never send these attributes to other
RADIUS servers not administered by you. Be sure you don't expose these
attributes any equipment that interprets the number you chose in a
fancy, unexpected way.
The reason why radtest saw hex stuff instead of text is most likely
because that radtest instance does not have the dictionary entry: it
doesn't know that what's coming in is a string. To be on the safe side,
it prints literally as a hex dump what it gets and leaves the
interpretation to you. The trivial fix is: propagate the dictionary
entries which we created above to all machines that need to know about
them, for example the machine from which you are running radtest.
If you have any further questions, don't hesitate to ask.
Greetings,
Stefan Winter
Justin Steward
I now have radius and SimpleSAMLphp communicating just as I'd hoped.
One final question. This isn't exactly a necessity, and I'm not sure if I will implement it if it is possible, but would just be nice to know if I can (and how, in that case). The usernames in our radius setup are of the form <username-<realm>. Is it possible to get SimpleSAMLphp to automatically append the -<realm> before submitting to the radius database? (We use the realms to keep accounts for each client using the radius server seperate.)
I haven't seen anything alluding to this in the comments scattered through the code, nor could I find anything in the mailing list or on the website.
~Justin
Stefan Winter
> One final question. This isn't exactly a necessity, and I'm not sure
> if I will implement it if it is possible, but would just be nice to
> know if I can (and how, in that case). The usernames in our radius
> setup are of the form <username-<realm>. Is it possible to get
> SimpleSAMLphp to automatically append the -<realm> before submitting
> to the radius database? (We use the realms to keep accounts for each
> client using the radius server seperate.)
>
> I haven't seen anything alluding to this in the comments scattered
> through the code, nor could I find anything in the mailing list or on
> the website.
Well, your problem isn't a SAML problem, but a RADIUS problem. Luckily,
FreeRADIUS can solve it for you :-)
In your server stanza in the authorize { ... } block you can set as very
first entry
authorize {
update request {
User-Name := "%{User-Name}-realm"
}
...
}
(um, exact syntax may be flaky; "man unlang" is your friend for update
statements)
Justin Steward
Well, your problem isn't a SAML problem, but a RADIUS problem. Luckily,
FreeRADIUS can solve it for you :-)
In your server stanza in the authorize { ... } block you can set as very
first entry
authorize {
update request {
User-Name := "%{User-Name}-realm"
}
...
}
(um, exact syntax may be flaky; "man unlang" is your friend for update
statements)
Greetings,
Stefan Winter
Sorry, took me a while to get back to you, been busy with higher priority tasks. Actually, I wanted to manipulate the username BEFORE it gets sent to the Radius server.
I'll try and explain in more detail.
We currently have one radius server with multiple realms. Say for example,
org1 and org 2.
In each realm say we have user1-org1, user2-org1, user1-org2, user2-org2.
What I want to be able to do, is something like this:
For SP at org1 (say google.com/a/org1.com) take user1 and turn it into user1-org1, send to radius.
for idp.org1.com, transform user1 into user1-org1
for idp.org2.com, transform user1 into user1-org2
The idea is to make the realms transparent to the end user, without doing something excessive like having a seperate radius server for each realm.
Stefan Winter
> Well, your problem isn't a SAML problem, but a RADIUS problem.
> Luckily,
> FreeRADIUS can solve it for you :-)
>
>
> user1-org1, send to radius.
In that case, it's indeed not a RADIUS problem. I would think that
authentication processing filters in simpleSAMLphp might help you - but
they would have to executed when generating the request at the SP, not
when getting the response back. Or alternatively, you want
simpleSAMLphp's RADIUS backend to do dirty hacks before doing the actual
RADIUS request. I think this would require (small) changes to the code.
I'm not really an expert here; maybe someone else from the list can take
it from here?
Greetings,
Stefan Winter
>
> Or, if that is not quite within reason, then the following, which
> should be somewhat simpler:
> for idp.org2.com <http://idp.org2.com>, transform user1 into user1-org2
> The idea is to make the realms transparent to the end user, without
> doing something excessive like having a seperate radius server for
> each realm.
>
> >
Justin Steward
In that case, it's indeed not a RADIUS problem. I would think that
authentication processing filters in simpleSAMLphp might help you - but
they would have to executed when generating the request at the SP, not
when getting the response back. Or alternatively, you want
simpleSAMLphp's RADIUS backend to do dirty hacks before doing the actual
RADIUS request. I think this would require (small) changes to the code.
I'm not really an expert here; maybe someone else from the list can take
it from here?
Greetings,
Stefan Winter
Mm, dirty hacks are one way to go, and it would be a convenient excuse to learn more about how it all fits together, but if there is a "proper" way for SimpleSAMLphp to mutilate a username before sending it on to the radius server, that would be much preferred, especially when it comes time for somebody else in the future to maintain the system, should I inevitably move on somewhere else.
Thanks, your help has been much appreciated during this little project.
~Justin
Solberg Andreas Åkre
Or, if that is not quite within reason, then the following, which should be somewhat simpler:What I want to be able to do, is something like this:
For SP at org1 (say google.com/a/org1.com) take user1 and turn it into user1-org1, send to radius.
for idp.org1.com, transform user1 into user1-org1
for idp.org2.com, transform user1 into user1-org2
Justin Steward
First, you are using the deprecated radius auth module. I'd reccomend you to try to switch to the 'new Radius module'. I would also be happy if Stefan would test the new radius module, as we do not use Radius for auth here.In the IdP documentation:there are listed a number of authentication modules. To use radius, configure your IdP to use radius:Radius as 'auth'. Then configure radius in authsources.php.Docs for Radius module here:
The links you provided are the documentation I used to originally try and get radius auth off the ground, along with the one detailing what to do for using it with Google Apps. For whatever reason they were unclear and not very useful to me at the time, and I stumbled along coming the solution I have working atm.
Upon re-reading, I understand better what to do, and now have SimpleSAMLphp authenticating using the radius:Radius plugin. I think having the deprecated module
Or, if that is not quite within reason, then the following, which should be somewhat simpler:What I want to be able to do, is something like this:
For SP at org1 (say google.com/a/org1.com) take user1 and turn it into user1-org1, send to radius.
for idp.org1.com, transform user1 into user1-org1
for idp.org2.com, transform user1 into user1-org2Some code modification is probably neccessary to achieve this. I guess in example the authsources.php radius configuration part could include a username-prefix and postfix to be added to the username the user types in.Then you can configure two idps for each domain, and point them to two different radius authsources with different configuration.
The code modification was actually quite simple. I've attached a modified version of the Radius.php.
I added 2 private variables ($userPrefix, $userSuffix), added 2 lines to get username_prefix and username_suffix out of the config in the constructor, and added one line to the start of the login function to add the prefix and suffix around the username. Simple.
Regards,
Justin
