WebAuth Developers FAQ
Authorization
How do I control which users have access to pages on my web
server? Where is the list kept?
The WebAuth service authenticates the ASURITE UserID and it is
upto the webmaster to setup a separate authentication as to which
ASURITE UserIDs should access a web page. For example, when a user
accesses a web page, a logon screen could then appear and ask
him/her their ASURITE UserID. This UserIDX could then be authenticated
against a list that the webmaster maintains and if the user is in
that list, he/she could subsequently be prompted for their
password. At that point the ASUWEBAUTH can be brought into the
picture and asked to authenticate the ASURITE UserID/password
combination.
Can I get user's affiliation information from
WebAuth?
It is possible to get some basic affiliation information using WebAuth.
However, this is not recommended for most situations. There is a large
performance penalty to WebAuth when returning affiliation information.
Developers are encouraged to use the "-n" switch to explicity turn off
affiliation lookup on WebAuth. Instead, it is recommended that developers
use other databases such as the Affiliate Database, Data Warehouse, or
Directory Services to get additional information about users.
IT is aware that developers need to make authorization decisions once a
user is authenticated. We are currently developing on online
authorization system to meet these needs. Further information can be
found in the Future Development
section.
Logging Out
How do I implement a Logout function?
The recommended solution is to use the WebAuth logout call:
https://weblogin.asu.edu/cgi-bin/login?Logout&onLogoutURL=http://www.asu.edu.
Just replace the onLogoutURL value with the page you want the
user redirected to upon logout. This call will clear any
references (e.g. credential file) on the WebAuth server, in
addition to clearing the browser cookie.
How long do users stay logged in? What is the lifetime of the
browser cookie and Kerberos credential?
The Kerberos credential lifetime is set to 9 hours on the
WebAuth servers. The cookie lifetime is for the browser session
à only. Once the browser is closed, the cookie is destroyed.
So, even if your browser session has been open for, say 10
hours, a "verify" of the cookie will fail since the credential
file on the WebAuth server expired at 9 hours. Upon failure, a
re-authentication of the user will establish a fresh credential
with a new 9 hour lifetime.
Please note that explicitly setting an expire time for a
cookie in a Set-Cookie: http header causes the cookie to be a
persistent cookie (stored on disk in cookies.txt or wherever the
browser keeps it) rather than a session cookie (in memory for the
duration of the browser's execution life). So trying to delete a
cookie yourself by setting an expiration time that you think is
in the past (but may not be if the client's clock/calendar is
off) may end up committing the cookie value to disk, which is
something you may not want to happen.
Testing
-
How do I test my production applications against upcoming WebAuth
changes?
- On your client machine (workstation), locate your "hosts"
file. On Windows, the default location is
C:\WINNT\System32\Drivers\Etc\hosts (although the
exact location may vary depending upon how your system is
configured). On UNIX, Linux, & MacOSX, the location is
/etc/hosts.
- Add the following line to your hosts file:
129.219.134.218 weblogin.asu.edu webauth.asu.edu
- Close all open browser windows, then you can open a new
browser and point to any WebAuth-enabled web application and
you will be testing against the Q/A WebAuth environment.
- When you are done testing, simply comment out the above
line in your hosts file (by putting a # in front). Then you
can uncomment later when you wish to test again. We recommend
only testing when you need to as the Q/A WebAuth environment
can be more volatile than the production environment.
For security reasons, I want to validate the contents of the
ASUWEBAUTH cookie before passing it to verify.
The valid encoding characters are 'A-Z', 'a-z', '0-9', '+', '-', and '_'.
The buffer size is 256. The verify client will only send a max of
256 characters to the verify daemon.
Troubleshooting
What is a "client host mismatch" and how do I resolve this issue?
This means that the client address provided by your
application server does not match the address of the client
browser as seen by the WebAuth server. Make sure that you use
the fully qualified domain name or IP address of the client to
pass on to the verify command.
There are two main causes for this error:
The user (client) is using SecuRemote and the application
web server is behind an encrypted CheckPoint firewall.
Users with SecuRemote enabled that access ASU computers
have their address translated by the border firewall into an
ASU address (e.g. 149.169). However, when those same users
connect to a machine behind an encrypted firewall, they
connect using an encrypted tunnel. This means that their
address is not translated at the border when talking to that
machine.
So, when a user that has SecuRemote enabled goes to a
web server behind a SecuRemote firewall, their IP address
appears to be the actual address of their machine with no
firewall translation. However, when they are redirected to
one of the WebAuth login servers, their IP address has been
translated at the border firewall to an ASU (e.g. 149.169)
address. After the user logs in they are redirected back to
the application web server, which then verifies the
authenticator by passing the authenticator and the user's IP
address as seen by the application server (i.e. the "real"
address of the client) to verify. When WebAuth receives
this verify call, it returns a client host mismatch error
because the IP address used to created the authenticator (i.e.
the translated ASU address seen by the WebAuth login
servers) is different from the IP address that was passed
(i.e. the "real" address seen by the application web
server).
The recommended solution to this problem is to make sure
that the HTTP and HTTPS ports (80 and 443) are OUTSIDE of any
CheckPoint firewall encryption (i.e. in a DMZ). This can be
accomplished by using a second dedicated web server. This
protects your application server from exposure outside the
firewall. We would like to stress ONLY the web server (HTTP
and HTTPS ports) should be outside the firewall to minimize
the exposure of the application server and database
connections.
The user (client) is using an ISP that utilizes proxy
servers. Sometimes, the ISP's proxy server will change the
address for a particular user mid-session, causing the
client host mismatch error. While it is difficult to
completely eliminate this problem, there are some steps that
can be taken to reduce the occurance of this situation to a
minimum.
- Ensure that your web server is configured to use
HTTPS. This is a known issue with other secure sites, so
many ISPs will attempt to maintain IP session affinity
when the client is communicationg over a secure port.
- The problem occurs when the users IP address changes
in between the time they login and the time their login is
verified by your application. A workaround for users is
to have them restart their browser and login again.
The verify.exe program returns the following error:
9:getservbyname error: 11004
9:Error: 10061 in connect()
Be sure you add the webverify 3001/tcp entry in
your services file (C:\WINNT\system32\drivers\etc
under Windows 2000). Be sure the file is named
services with no extension. There is a file called
services.sam which is a sample file and should be
renamed. Also, be sure you have a carriage return after the last
line of the file (make sure there is a blank line or two at the
end of the file).
You shouldn't need to reboot, the change takes place
immediately. To test it, type telnet webauth.asu.edu
webverify at the command prompt. If you get a
connection refused, try telnet webauth.asu.edu 3001
If the first attempt is refused and the second connects, then the
change to the services file did not work.
Why is WebAuth returning 1:expired?
This response from Webauth indicates an expired credential.
The user will need to reauthenticate.
Verify returns the same values I
sent to it.
When you execute a 'verify' command such as:
e:\verify -h:webauth.asu.edu -b:129.219.xxx.xxx
-c:IiJKhA_Bk4Q78gF3Ipd5cHfwf47x4HXJE358EMGQcu58jRrojpQotMsPtRtL8RGdjGllllllllll
you expect it to return something like:
0:[userid]@ASU.EDU:PRIMARY:[AFFILIATION]:[DEPTCODE]
but instead it returns the values you just sent:
IiJKhA_Bk4Q78gF3Ipd5cHfwf47x4HXJE358EMGQcu58jRrojpQotMsPtRtL8RGdjGllllllllll:129.219.xxx.xxx
The server executing the 'verify' command must have its IP address registered
so that it has a DNS name. Otherwise the reverse DNS lookup fails, causing the 'verify' command to fail. In addition, if an invalid cookie value is passed to 'verify', it may behave similarly, i.e., it echoes back the values sent to it.
|
