Re: [RADIATOR] Shibboleth authentication for wifi

[Simon Lundström]

My colleague emailed Denis off the list. We have implemented this and it
works well (too well because it makes people not use eduroam) but there
are a few limitations to the solution.

On Mon, 2012-01-16 at 17:25:24 +0200, Heikki Vatiainen wrote:
> On 01/13/2012 03:43 PM, Denis Pavani wrote:
> 
> > My company plans to have a wireless network where authentication 
> > credentials come from a federation using shibboleth.
> > We have in production a cisco wireless controller, and really I was 
> > trying not to bypass it for a different captive portal.
> > Is it possibile to use "authby URL" redirecting creentials to a cgi
> > which provides shibboleth authentication?
> > Does anyone have experience with this?
> 
> I think this model is too straightforward to work. You need to allow
> passthrough for every organisation that participates in the federation.
> The users need to access the authentication web page of their home
> organisation.

Yes and this is possible with parsing the federation metadata, find the
IDPs and automatically create/update an ACL within your wireless
controller.

There are two gotchas/limitations with this step:
* The wireless controller we are using limits the ACL for the walled
garden to 50 (or so, can't remember) entires. So this limits the number
of IDP:s that we can support.
* Creating automatisation for updating the ACL is, IMO, hard but someone
that is better at this might have better luck with it. You can do this
via telnet/ssh&&expect or via the WS SOAP API to the WCS which I don't
think is sanctioned or documented by Cisco (not what we have found
anyway).

> After the authentication the user is redirected back to your login web
> page and the web server sets the environment variables to reflect the
> outcome of user's authentication. That is, you do not get any access of
> credentials you could use to do the login. To actually use this
> information, you would most likely to bypass the controller to utilise
> information from shibboleth.

Well, since we don't trust the RADIUS protocol enough to use our "real"
passwords (we have a seperate identity, and thus password, for using
eduroam) but we still want to be able to verify the user; our workflow
looks like this compared to the one that Heikki described:

1. In the wireless controller use the auth by external-feature and point
this to a Shibbleth protected CGI. We use a Discovery Service/WAYF for
this so that people can choose their home organisation.

2. The success URL users get from their home shibboleth login directs
them back to your web server.

3. The resource pointed by success URL (e.g., CGI script) generates a
user, shared secret and time-based token which is hashed. This token can
later be verified by Radiator.

4. The user is redirected to controller's login page with GET or POST
request type. The request parameters specify the temporary username/password

5. Controller does RADIUS authentication and Radiator verifies the
token.

6. If the authentication is successful, as it always should be at this
point, the controller opens the captive portal. The user has now logged in.

- Simon

---

Simon Lundström
IT Services
Stockholm University
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Change speed rate limit for selected URL or service

[Heikki Vatiainen]

On 01/18/2012 09:37 AM, Purevbat. Ya wrote:

Hello,

> We would like to set different speed rate limit on selected URL or
> Selected URL Group.

This sounds like something that needs to be supported by network
equipment (access gateway, router, etc.) that has been designed to do
such rate limiting.

The sites you list are likely to use content distribution networks where
there are many IP addresses that serve the content based on user's
location. In other words, making a list of which IP addresses need to
rate limited would need specialised software built for this purpose.

However, it might that e.g. all Facebook servers are within on IP
address block. If so, then rate limiting can be possible with more
general purpose network equipment too.

When using Radiator, Radiator can return specific attributes that assign
different rate limit groups for users A, B and C. When the user logs in,
group identifier is fetched from e.g. SQL during the authentication
process. The identifier is then returned with RADIUS Access-Accept.

Lets say identifier '1and3' is what user A should get.

The rate limits in this case would be prepared in advance. When access
is accepted and there is a rate limit identifier '1and3', this would
rate limit A's traffic as you had in your example.

RADIUS protocol can also be used to return rate limiting information
directly with each Access-Accept when using appropriate RADIUS
attributes. These attributes could list IP address blocks with their
respective rate limit information.

Please note that what I wrote was to give some ideas instead of going
into too much detail. More detailed information requires knowing more
about your setup and what equipment you have or plan to use.

In summary: what you describes sounds possible. When you evaluate
equipment that support the functionality you require, look for what is
supported via RADIUS. If the equipment supports setting rate limit
information via RADIUS, there is quite good possibility Radiator can be
used as the RADIUS server.

Thanks!
Heikki


> Example A: Customer A have 1mbps speed rate limitation. But he/she could
> visit www.facebook.com  by 3mbps.
> 
> Example B: Customer B have 1 mbps speed rate limitation for regular web
> sites and protocols. But he/she could visits to www.facebook.com
> , www.twitter.com ,
> www.youtube.com  by 3mbps.
> 
> Example C: Customer C have 1 mbps speed rate limitation for regular web
> sites and protocols. But when he/she try to use torrent or torrent like
> p2p application his/her speed rate limitation will become 500kbps.
> 
> Is it possible?
> 
> We’ll looking forward to hear from you soon.
> 
> Tnx.
> 
>  
> 
> BR,
> 
> Purevbat.Ya
> 
>  
> 
> 
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Prepaid Card solution.

[Heikki Vatiainen]

On 01/18/2012 09:27 AM, Purevbat. Ya wrote:

Hello,

> First I’ll try to describe our billing & Radius server’s current status.
> 
> When customer made their payment we’re setting one month access
> permission on AAA server like: 2012.Jan.18 – 2012.Feb.18
> 
> This customer access will expire Feb 18^th even customer didn’t even
> logged first 10 days.
> 
> What we would like to do is:

This is possible with Radiator. For a simple prepaid case, please look
at file goodies/prepaid.cfg  As you can see, this example uses SQL
database which is updated by different RADIUS requests.

For more complex cases, such as what you are planning, the functionality
can be implemented with user defined Hooks that run during
authentication process.

For example: once password authentication is successful, a hook called
PostAuthHook is run. The hook can then access the prepaid SQL database
and update the information based on the rules you specified.

For more information about the hooks, see the reference manual ref.pdf
and goodies/hooks.txt file in the Radiator distribution.

These kinds of hooks have been built but as in your case, they are not
generic but depend on e.g, database, what information is required and
available about users, authentiation process and other case by case
requirements.

So in summary, what your require looks possible. I do know these kinds
of time based quotas have been implemented for e.g. Wi-Fi guest access
purposes.

Thanks!
Heikki


> When customer made their payment we should set two date ranges.
> 
> 1.   2012.Jan.18 – 2012.July.18 this range’s meaning is when
> customer didn’t used his/her modem.
> 
> 2.   A. Add 30 days to customer’s account. Expire date should be +30
> days since customer first used his account. Ex: Payment made on Jan
> 18^th but customer 1^st used his/her account on Jan 23th. In this case
> expire date should be Feb 23th.
> 
> B. is there any options that 30 days are decrease only when only when
> customer logged or not on that day. Ex: Jan18th 30 days remaining.
> Customer logged on Jan 21th, Jan 22th, 23th and 28th. On Jan 30^th
> Remaining Day: 26 Days left. (because 4 days used.)
> 
> (In this case we didn’t mentioned about data volume. J please consider
> like data volume not reached to 0)
> 
> We would like to use Prepaid card, prepaid card works like mentioned above.
> 
> Is it possible?
> 
> We’ll looking forward to hear from you soon.
> 
> Tnx.
> 
>  
> 
>  
> 
> Хүндэтгэсэн,
> 
> Я.Пүрэвбат
> 
>  
> 
> 
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] RADSEC and Secret

[Alan Buxey]

hi,

having issues with an older version of RADIATOR - seems to not be liking
the 'Secret' being setthe old version (and current version) have 'mysecret'
as default..which doesnt match the current drafts etc - which is now 'radsec'
my servers (4.9) are very happy with Secret being definedbut a remote
server running older 3.x flavour is no longer able to send packets after
it was reconfigured to use the new standard Secret.

when did Secret get supported in AuthBy RADSEC ?

many thanks

alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] RADSEC and Secret

[Heikki Vatiainen]

On 01/19/2012 04:27 PM, Alan Buxey wrote:

> having issues with an older version of RADIATOR - seems to not be liking
> the 'Secret' being setthe old version (and current version) have 
> 'mysecret'
> as default..which doesnt match the current drafts etc - which is now 'radsec'
> my servers (4.9) are very happy with Secret being definedbut a remote
> server running older 3.x flavour is no longer able to send packets after
> it was reconfigured to use the new standard Secret.
> 
> when did Secret get supported in AuthBy RADSEC ?

It was there since the first version 3.12. I just tried with 3.12 client
and server config against 4.9 server and client config and they were
able to talk when Secret was changed to radsec.

With 3.12 you have to enable UseTLS explicitly. That was the other
change apart from port number I had to change to make 3.12 talk to 4.9.

Heikki

-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] RADSEC and Secret

[Alan Buxey]

Hi,

> It was there since the first version 3.12. I just tried with 3.12 client
> and server config against 4.9 server and client config and they were
> able to talk when Secret was changed to radsec.
> 
> With 3.12 you have to enable UseTLS explicitly. That was the other
> change apart from port number I had to change to make 3.12 talk to 4.9.

hmm, okay then - thanks - the UseTLS is already there.  I see the socket 
connection
occuring...so might be some other issue... strange. it all worked with the 
default
(no secret defined - hence 'mysecret' password).  

any news/time for when RADIATOR will use the TCP connection to understand the 
presence
of the remote server (rather than its current 'keep blatting away' method?)

cheers

alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator