Q: How do I get my NetID?
A: Follow the Activate
your NetID link and follow the directions on requesting a
NetID.
Q: Do I have to be a student to use this system?
A: No. This system is available for use by students, faculty, and
staff of the Texas A&M System and its affiliates.
Q: How long is my session valid?
A: Once you login, your session is valid until you close all instances
of your browser, request a logout, or 2 hours, which ever happens
first.
Q: What is CAS?
A: Central Authentication System. It is a java application that
runs on a dedicated server, netid.tamu.edu or netid-dev.tamu.edu
for development. It maintains state and authentication data on
clients. It was initially developed at Yale University and modified
to work with the new NetID and LDAP deployment at Texas A&M
University. Client software on other web services connect to
the netid.tamu.edu server to authenticate and process user login
requests. Cookies must be set on the client browser for the service
to work properly.
Q: I authenticated using Netscape but my Internet
Explorer I am also running is asking to be authenticated again?
A: Authentication is valid for a single browser. If you use two browsers
or browsers on different machines, you will need to authenticate
again inside each browser.
Q: How does CAS work?
A: There are three phases to CAS authentication.
The first is to check to see if the user has logged in. This is
done by calling the cas server at https://netid.tamu.edu/cas/login
andpassing the web service as a service parameter such as
?service=http://netid-dev.tamu.edu:81/cgi-bin/secure.cgi
The CAS server either redirects the user to your service page passing it a ticket or takes the users browser to the login page and requests that the user logs in using their NetID and password. The CAS service stores some cookie information in the users browser to assist it with finding the records that are used to bypass the user login process where appropriate. Your web service page is then required to call the validation service at https://netid.tamu.edu/cas/validate and pass the web service and ticket returned from the login process.
This second step is required so that users don't get fooled by
imposters granting invalid tickets and invalid authentications. If
the service and ticket values are valid, the CAS server returns a
stream that contains four lines. The first line contains a yes or
a no. If it is a no, no additional lines are returned.
If the first line is the text string yes, the next line
will contain <NetID>value</NetID>. The third
line will contain <UIN>value</UIN>.
The third phase of CAS authentication is really a recommendation. It is suggested that each web service create a session so authenticate with other services on the same application/web server. If a valid session exists on the web or application server, there is no need to call the CAS server for authentication.
Q: What is returned from CAS?
A: After a successful login, there are two values that can be
returned.
The traditional legacy validation, called with /cas/validate,
returns:
yes (new line)<NetID>value</NetID> (new line)<UIN>value</UIN> (new line)The CAS 2.0 validate, called with /cas/serviceValidate, returns:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> (new line)
<cas:authenticationSuccess> (new line)<cas:NetID>value</cas:NetID> (new line)<cas:UIN>value</cas:UIN> (new line)</cas:authenticationSuccess> (new line)</cas:serviceResponse>
Q: Can I redirect the logout to go to my web page and
not the CAS logout page when a user logs out?
A: Yes. To log a user out of cas, your application should make
a call to https://netid.tamu.edu/cas/logout. If you add
the additional parameter
?service=http://yourserver/your_web_page
the cas server will put the user on your servers web page that you specify.
Q: What cookies are stored in my browser?
A: Two cookies are stored in the users browser by the CAS service.
The first is a session cookie stored by the application server.
This cookie is used for load balancing and session preservation
across servers. The cookie is named JSESSIONID and has an encrypted
value that ties it to the host and /cas authentication
service on that host. The second cookie is placed there by the
CAS server and has the name CASTGC. The value stored in this
cookie is the host of the CAS server, a link to the /cas
authentication service on that host, and an index into the session pointer
on the server. Both of these value are destroyed when the browser
exits, the session expires, the CAS server is restarted, or the
/cas/logout service is called from the browser or web service that
the browser interacts with.
Q: I am developing a program for students and faculty
and want to use this service to authenticate users, how do I do
this?
A: Download the client interface libraries
and integrate them into your web pages. There is
sample code modified to work in the TAMU environment for:
New development continues for CAS clients and the central distibution site at JA-SIG.org would have the most up-to-date list of client ports. If you need more assistance, contact the CIS staff and request programming assistance. In many instances the changes are relatively trivial and don't require much knowledge or detailed understanding of the CAS environment.
Q: I need to let a vendor, parent, or visiting faculty
member have temporary access to some data that I am protecting. How do
I get a NetID assigned to them so that they can authenticate and
see the information that I want them to see?
A: This is a difficult question that is not answered by the CAS
software. CIS is currently evaluating modifications to the
Neo/LDAP/Kerberos implementation to allow for this temporary
authentication. The CAS software is dependant on the data from the LDAP and
Kerberos servers so getting the user information into these repositories
is the only requirement. No changes are needed in the CAS software,
just the data that it reads.
Q: Is there a server I can use for testing?
A: CIS has established a test environment hosted on netid-dev.tamu.edu.
The server provides the same services as the production systems
and uses the same call interface. Replacing netid with
netid-dev in
your CAS calls will access the test server. The test server still
uses the production LDAP servers for now. CIS is researching adding
a test LDAP service that will allow for creating different NetIDs
with varying attributes. However, for now, the test server calls
operator.tamu.edu for
authentication.
Please note CAS utilizes SSL for communications from and to an application. For the production servers, a certificate purchased from Thawte is used. However, for test and development purposes, TAMU locally signed certificates are used. The TAMU Signing Authority Certificate can be found at cis.tamu.edu/CA as well as instructions for how you can request your own TAMU signed certificate. You will need to scroll to the bottom of the page to find the information. For some environments, adding the TAMU CA certificate to the list of trusted hosts or to the certificate ring will avoid getting a popup to verify the certificate.
Q: Where can I find more information on CAS?
A: The central repository for CAS development is on JA-SIG.org.
This site is maintained by the developers and covers topics from
architecture to implementation. The CAS 2 architecture document
builds upon the CAS 1 document, so be sure to read both documents
for the full view of the CAS architecture. The protocol document
covers both versions. As of March, 2006, CIS is running CAS 2.