Navigation
What is the reply format of the authentication portal ?
Mon, 08/15/2011 - 16:20 — slashene
I'd like to create my own portal for authentication.
If I understand, authentication need to be done by this portal and provisionning/accounting is handled with a Radius server or Http server (with an embedded proxy on the hotspot which convert radius to http).
However I don't find any documentation about the return values that the portal should reply if the authentication succeed.
Do you have any documentation or open source project so I can see how I can do that ?
I've downloaded the source code of coova chilli and seen the code of MiniPortal. However I have to admit that I don't find what I'm seeking... not very used to shell language. :(
Thanks,
- Login to post comments
Quote:I'd like to create my
Fine.
Authentication is done by the radius server, the captive portal just relays the login details and gets from the radius server where and what the user sees.
Http server only serves content. no radius to http "conversion" occurs. conversion of what?
Reply to who?
The captive portal gets its info per user/group from the radius server. If the user has a time limit, a url that the user gets rediected to after successful login, speed of connection etc., the cp can get these from the radius server.
Where the user can go before login and some other things are controllable by the cp's config file.
The cp uses some "attributes" from the radius server before/after authentication to control the users.
These attributes are listed in th cp's documentation, and the radius server uses a "dictionary" supplied by the cp's developers to see what attributes a cp may be able to process.
Thanks for your response, no
Thanks for your response,
no radius to http "conversion" occurs. conversion of what?
I was talking about that, but that's not really important : http://coova.org/CoovaChilli/Proxy
What I don't understand, is that you say
Authentication is done by the radius server, the captive portal just relays the login details and gets from the radius server where and what the user sees.
Http server only serves content.
However the Http server is not necessarily on the CP. So my question is, how the CP get these login/password informations, since when the user submit the login form, it send a request to the Http server, not to the CP (even if the traffic pass through it) ?
I thought that my Http server should return a formatted HTTP response to the user that the CP can intercept the user name and grant network access. (After verifying permissions on the radius server)
ok i see..
sure
i checked out
http://coova.org/CoovaChilli/Proxy
I''l have to go back and re-read it a few times, so i get the picture....
However the Http server is not necessarily on the CP. So my question is, how the CP get these login/password informations, since when the user submit the login form, it send a request to the Http server, not to the CP (even if the traffic pass through it) ?
Ok, here's roughly how it goes...
The cp acts as a deliverer of the content, regardless of whether that content is on itself, or somewhere else, like another web server.
The cp knows where the the initial landing page(s) (content) are because its config sez where to get that from. It might be on itself or anywhere.
It also knows where the login script or pages are for the users to authenticate to get access.
When the user logs in the login script because of the construction of the cgi or php page that does the authentication the cp takes what is returned by that script (username etc) through the users browser and chucks it at the radius server.
The login script is designed to sort this out (and know where to direct the users browsers) with the cp.
Whatever is doing the serving of the content (the web server) knows nothing about this, as such it just serves (acts as a slave to the cp sort of )up the content of the script and the cp, the browser and the script do the rest.
When the cp gets its part of the scripts output it it uses the parameters sent from that script to itself via the browser and tries to contact the radius server to authenticate the user using radius udp packets.
There is no authentication using the web server, inbuilt or apache etc, to happen.
It does NOT send a request to the webserver or anything to the webserver.
I thought that my Http server should return a formatted HTTP response to the user that the CP can intercept the user name and grant network access. (After verifying permissions on the radius server)
No sorry that is not what happens afaik. the only redirect that is sent to the user via http is a success or ( :-(( ) failure page depending on the where the radius server tells the cp where those are, if any.
These pages are be also stored (and delivered by ) either on the cp itself or a seperate web server, but the user is redirected to those by the cp.....the http server is again not involved except as a repository for the pages the browser needs to see....it is not involved in the authentication at all...
Is that any clearer? i know its a bit confusing....lol...
Thanks, it seems clearer to
Thanks, it seems clearer to me.
Exept one part
When the user logs in the login script because of the construction of the cgi or php page that does the authentication the cp takes what is returned by that script (username etc) through the users browser and chucks it at the radius server.The login script is designed to sort this out (and know where to direct the users browsers) with the cp.
The question is how the login scirpt sort this out ? (Get the username + password the user just entered)
your login form passes those
your login form passes those to hotspotlogin (php or cgi), chilli reads that or is passed the parameters and does the rest.
i don't know the actual mechanism in the code of coova.