NetID Login Service - Frequently Asked Questions
- General Questions
- End User Questions
- Developer Questions
- What webservers are supported?
- What do I need to make it work for my website?
- How do I handle Authorization?
- How do I get someone a NetID if they don't already have one?
- Does all of my content have to be delivered over SSL?
- How to configure logout?
- How do I migrate a NetID Login Service app to a new server?
- How can I configure SPs in a Load Balanced configuration?
- Are there different environments for production, QA, and test applications?
- What URL should I use for the IDP EntityID/Metadata?
- I'm getting this error message.....
The NetID Login Service is a WebISO (Web Initial Sign-On), which is a technology that allows a large community of applications to use a central login credential (NetID & password) to authenticate users while simultaneously reducing the risk of account compromise. This is accomplished through the use of a central login service, and application modules that redirect to and from the central login service.
- Shibboleth is the product that provides WebISO service for UW-Madison.
If people are having problems logging into NetID Login Service(WebISO)-protected applications, these instructions will help to determine if the problem is with the NetID login servers or with the application:
Try logging in to both of these servers (you can ignore any SSL certificate mismatch warnings presented by your browser):
Clicking each link should bring up a browser window prompting you to log in with your NetID and then displaying "Hello World" after a successful login. This indicates that the login server is functioning properly.
If the test succeeds for both links, the NetID login servers are functioning correctly and the problem is with the application (either in their local WebISO configuration or their Authorization).
If the test fails for either link, one of the login servers is down.
A current listing of browsers can be found in NetID - Recommended Browsers.
It can sometimes be hard to tell if you are logged out or not. The best way to ensure that you are completely logged out is to close your web browser and clear your cookies (see NetID Login Service - Logout Procedure).
The previous user did not log out of their NetID session. If a NetID session simply expires or an application requests
re-authentication(such as My UW-Madison), you will see the NetID of the previously (or currently) logged-in person.
If you see someone else's NetID in the login box, the best thing to do is completely close the browser (all windows) and clear your cookies (see NetID Login Service - Logout Procedure).
When you use an icon on your desktop (or quick-launch bar), a new browser session is opened. This is an intentional security feature. If you open a new window via CTRL-N or File->New->Window, and use a bookmark, it will use the same session and multiple logins will not be required.
Shibboleth supports Apache and IIS web servers. For complete details, see Shibboleth's documentation.
Minimally, you need:
- A supported web server (see above)
- A web server with accurate time, meaning NTP-synchronized (see DoIT NTP servers)
- Shibboleth Service Provider installed and configured
There are a few ways to provide people with a NetID, depending on the situation.
- If someone is ineligible for a NetID but loosely affiliated with UW Madison, such as a consultant, you may consider requesting that Human Resources create a special appointment for them (such as Spec Auth or POI). This will make them eligible to activate a NetID. Talk to your HR department for more information.
- You may be able to invite people who are not affiliated with UW Madison to create a NetID if you have a strong business case and are approved. For example, if you are working with an application vendor to integrate the NetID Login Service with their app, this could be used to facilitate testing on their end. See Manifest - Using a Manifest Group to Invite People to Create Identities (NetIDs) for more information.
- For non-affiliates of UW Madison, Guest NetIDs can be provided for a limited duration under certain circumstances. See [Link for document 3455 is unavailable at this time] for more information.
For Shibboleth to provide secure authentication, you need to make sure your application server's Shibboleth SP communicates with the login server over an encrypted connection, so that user-specific data is not passed over the internet in plain text.
For more information, see NetID Login Service - Importance of Secure Cookies.
Single Logout in the context of the UW NetID Login Service would be the action of clicking a Logout link or button that would cause the user to be logged out of all NetID Login-protected applications at once. Currently, Single Logout is not possible in the UW NetID Login Service. There are many reasons for this, and if you're interested in details this document provides a good overview.
The only complete NetID logout is closing the browser and clearing all session cookies, which is the end user's responsibility. End users can review instructions on clearing cookies and making sure their browser is safely configured here: NetID Login Service - Logout Procedure.Logout of individual applications
Application developers can use the central NetID logout page (https://login.wisc.edu/logout) as a way of requiring users to sign back in with their NetID in order to:
- return to the most recently used NetID-protected web application or
- access any NetID-protected resources not previously visited during that browsing session
In Shibboleth, redirection to the central logout page can be done by using the Logout property of the Shibboleth handler to perform a Local Logout and attaching a return value that redirects the user to the UW NetID Login Service logout page.
Here's a sample logout link for the application example.dept.wisc.edu:
It is not necessary to coordinate a server migration with the NetID Login Service team. By following these steps, Shibboleth will continue to function seamlessly when you cut over to the new server.
- Rather than generating a new Shibboleth2.xml file, simply copy this file over to the new server.
- Put the login.wisc.edu-signing.pem file in the appropriate directory of the new server.
- Copy the sp-key.pem and sp-cert.pem from the old server to the new server (replacing these files if they already exist on the new server).
- For IIS-Shibboleth Users: The new IIS server may generate a new Site ID value for your service, you will need to check to make sure that the <Site id> in your shibboleth2.xml matches the IIS ID value. This is particularly important to check if you have multiple sites. You can find the Site ID value in the IIS Manager: Your Server > Sites > ID column
These steps should result in the NetID Login Service continuing to function immediately after the server migration. If there is a need to change anything in the Metadata, for example you are switching to a new sp-key.pem and sp-cert.pem, you will need to contact the the NetID Login Service team to upload the updated Metadata file.
Configuring Load Balanced servers for Shibboleth is very similar to a standard SP configuration, with a few additional things to be aware of:
- All load balanced hosts should contain an identical Shibboleth cert/key pair.
- The load balancer URL should be the endpoint for generating the Metadata, since traffic to that URL will be directed to one of the actual hosts.
- The URLs of the hosts themselves do not need to be added as Shibboleth locations/endpoints, unless there is a need to have users bypass the load balancer and navigate directly to the hosts.
- The load balancer should be configured with persistence for proper functionality with Shibboleth.
You can choose to use the Production, QA, or Test environment of the NetID Login Service for your application. Production and QA both use "real"/production NetIDs and passwords for authentication, while Test uses special test ("ITE") credentials that most users do not have by default. The test environment should only be used if it is absolutely necessary to integrate with ITE data or other ITE applications, otherwise QA should be used for the vast majority of non-production applications.
When you contact the NetID Login Service team to have your application authorized as an SP, make sure to let them know what environment you will be using. If you are still not sure which to use, contact firstname.lastname@example.org for assistance.
The IDP Metadata is available at the following URLs:
NetID Login Service - Common Errors. If you're getting an error not listed there, please email email@example.com
Important: If you are an application manager, please indicate that fact in your communication and include the text of the error and the FQDN of the server.
You can also call the DoIT Help Desk at 264-4357 or open a case online at the Helpdesk Page (once there, click on "Create a New Case" from the left menu options).