WLC Web Authentication Methods and Semantics

[laaustin]

It appears that somewhere between AireOS 3.0 and 3.2 the choice of web auth changed. Initially, I believed two choices existed - using the onboard wlc 'local net user' datastore or offloading the authentication to another web server who in turn notified the controller of success/failure thru a value in the html object used in the auth process (between the external web server and the user).

Now I fail to see something that resembles the latter method. I now see that we can choose between local net users and RADIUS, with the choice of modifying the onboard html or using a login page from an external server (in realtime or via the 'login bundle').

I got no concept of what's really going on here. Can someone help - especially someone that's done something along the lines of using a non-RAIDUS, offboard layer 3 authentication scheme?

Thanks

[smahbub]

Hope the following link will help you

http://www.cisco.com/en/US/products/ps6366/prod_technical_reference09186a00806cfa96.html

[laaustin]

I'll take another look at this (the manual)... Can I presume you possess experience with using off-controller web auth, or did you just decide to offer a manual reference? Apologies for appearing flip or ungrateful, but manual references sometimes don't meet the need... and also, I seek a sanity check on the matter of whether the web auth method changed from the early days... Do you or anyone else on the forum possess experience with guest authentication scenarios, especially with off-controller authenticators - not of the RADIUS interface???

Thanks...

[laaustin]

Hmmm... found a document specifically http://www.cisco.com/en/US/products/ps6366/prod_technical_reference09186a0080706f5f.html produced around 10Aug2006 that speaks of several options for guest authentication, including web auth on an external device (web server).

I'm confused by the following text:

"Once authenticated at the external login page of the external web server, a request is sent back to the controller. The controller then submits the username and password for authentication to an external RADIUS server for verification.

If verification at the RADIUS server is successful, the controller web server either forwards the user to the configured redirect URL or to the user's original opening web page.

If verification at the RADIUS server fails, then the controller web server redirects the user back to the customer login URL."

If I use an external authenticator, why does the controller call RADIUS? The document also fails to indicate (at least explicitly), how the external authenticator communicates to the controller the pass/fail state of the external authentication process...

Any takers?? Seriously... anyone experienced with this issue - and willing to share your valued insight???

[Stephen Rodriguez]

So out of curiosity, what do you mean by Non-RADIUS off board authentication? And yes in prior and current code, you can send the guest user to a completly external box that was doing some sort of webauth. Just in the 4.0 they introduced being able to upload a "customizable package" to the controller itself. And yes, by default the WLC will look in the Local Net Users database, and if there is no entry there, it will then query the configured RADIUS server to see if the guest user is listed there. But this only happens if you are using the controller for the webauth. If you set it to go to an external server, WLC doesn't pay any attention to the acutal authorization anymore.

[laaustin]

Thanks for the clarification...

I interpreted the text I supplied in my previous post to mean that the controller unconditionally called RADIUS, even when using an external web authenticator. What I mean by non-RADIUS refers not having RADIUS involved...

Now, again for my understanding, exactly what signals the WLC to pass traffic for the successfully external-authenticated guest user? I'm not much of a html type, but I do feel the documentation can be more explicit...

Again, thanks very much for making the guide more clear...

[Stephen Rodriguez]

Nothing. If you specify that you are using an external means of validating the guest user, the WLC has no need to know if the authenticatin has been accepted, it just needs to know that another device is handling it, and pass along data as normal. It will rely on the other means, to stop traffic if it is not allowed.

[laaustin]

Ok... I guess I failed to realize that 'web auth' also implies some other device lies in the data path to control traffic as the WLC no longer participates in traffic control based on the authentication result determined by the external web auth device.

Kind of unfortunate... I was told back in the Airespace days that the external web authenticator would somehow signal the controller to pass/block traffic, but never understood how...

What does the last sentence in your reply expand to mean? What other means in the external web auth scenario will the WLC use to stop traffic related to failed external authentication?