MTU ISO - How it works

The initial sign-on process is illustrated below. Each step is explained below the diagram.


  1. A user makes a request to an application protected with MTU ISO for authentication.
  2. The MTU ISO module intercepts the request and inspects it to determine if a valid authenticated credential is already present for the requestor. The authenticated credential is represented by a specifically named cookie with an X.509 digital certificate as its payload. The digital certificate is signed by a private key so only the holder of the public key, which could be one or more applications, can validate the certificate. Further, the cookie is scoped to the application's domain (e.g., email.mtu.edu) so it will only be presented to the specific domain of the request.

    • If the appropriate, local credential is found:

      • It is verified against the application's local public key using standard X.509 verification.
      • If MTUISOIPCheck is on then the requestor's IP address is verified against the IP address in the digital certificate.

    After that the user is considered authenticated and the MTU ISO module proceeds to the authorization phase. If the user is authorized the web server presents the user with the requested resource. Please note that the application may perform its own authorization at this point.

  3. If the appropriate credential is not found. The MTU ISO module generates a redirect to the central login server. The redirect MUST contain:

    • The global cookie name this application wants when/if the user returns
    • The URL to use to return the user from the central login server back to the application
    • The application's ID number

    The redirect MAY contain:

    • A random number that the application asociates with the requestor's IP address and "remembers" for a short period of time so it can validate the requestor's eventual return from the central login server. This random number is sent automatically in the crosscheck parameter if MTUISOGlobalCrosscheck is on.
    • A time-to-live for the application authentication response in seconds. This is specified by sending the globalttl parameter.
    • A flag indicating the security of the application authentication response sent in the globalsecure parameter. Set to 1 to make sure the response is only sent over an HTTPS line and to 0 or unspecified if you don't mind HTTP.
    • The central login server may accept other parameters. Please visit the central login server parameters page for the entire list.

    We will call this the Application Authentication Request.
  4. The central login server receives the application authentication request. Upon reception it attempts to determine if the user has a valid central login server credential. We will call this the Central Granting Credential (CGC). The CGC cookie is scoped to the central login server domain and so will only be presented to the central login server.

    • If the user does not have the CGC the central login form is presented to the user.
    • If the user has the CGC the credential is verified against the CGC's public key using standard X.509 certificate verification. If the CGC is verified the user is considered authenticated and the process skips ahead to step 8 with a "yes" response.
  5. The user enters his or her username and password into the form and submits it causing the browser to send the data to the central login server, preferably over a secure protocol like HTTPS.
  6. The central login server takes the username and password and sends them to an authentication service for verification (LDAP, Kerberos, etc.).
  7. The central login server receives some sort of response from the authentication service that indicates if the user has proven identity, most likely a yes/no response.
  8. If the response indicates a "no", the process goes back to step 4.
    If the response indicates a "yes":

    • The application ID is looked up in the application registration database and it is determined if this application is enabled or disabled. If the application is disabled or the ID is not found, an error message is generated by the central login server and processing stops immediately.
    • If the application is enabled the redirect parameter (back) is verified by making sure it uses the Base URL specified when it was registered. If the Base URL and redirect are not a "match" then the central login server generates an error message and processing stops immediately.
    • If the application passes the registration checks, a cookie is generated with the name specified in the application authentication request.
    • The cookie payload will be an X.509 digital certificate that contains the random number specified in the application authentication request as well as certain attributes that the MTU ISO module needs to determine who a user is (e.g., login id).
    • The digital certificate will be signed by the central authentication server's private key. If a globalttl was specified then the credential's expiration will be set to that many seconds otherwise the default will be used (10 seconds). It is important that the time limit be small because this cookie is scoped to the entire low level domain (e.g., mtu.edu). If globalsecure was set to true then the cookie will be marked secure and will only be presented over an HTTPS session.
    • The cookie is presented to the application when the central login server generates the redirect specified in the application authentication request. This will be known as the Application Authentication Response.
  9. The application's MTU ISO module receives the application authentication response and proceeds as follows:

    • Validates the globally scoped cookie's payload using the central login server's public key. This validation includes a time check. Remember that the global cookie should have a very short expiration time.
    • Retrieves attributes from the cookie payload.
    • If MTUISOGlobalCrossCheck and MTUISOIPCheck are on: Checks the random number and requestor IP address to see if they are the same as it "remembers". If it no longer remembers we proceed back to step 3.
    • If the random number and requestor IP address are not the same the application "forgets" the association immediately and starts over from step 3. If the random number and requestor IP address are the same the application "forgets" the association immediately to avoid a replay attack. It then issues a new cookie, scoped to its local domain, with an X.509 digital certificate payload signed by its own private key.
    • We now proceed all the way back to step 2 where the user should be considered authenticated.

This idea is not new which is why it works so well. The idea is based on Kerberos' notion of tickets. In this web model there is room for a man-in-the-middle attack, but it is quite a difficult one. It requires spoofing the application's hostname in order to steal the valid globally scoped credential, storing the stolen credential in the appropriate cookie name, then spoofing the requestor's IP address to present the valid credential with the valid cookie name to the real application server. This all must occur before the timeout value of the global credential or before the real person gets to the application server because as soon as the real user gets there, the random number that will be checked becomes invalid.

Please note, it is not possible to stop the authentication phase from redirecting at least once. However, it is still possible to put this module in a chain of Apache authentication modules. If you specify MTUISOAuthoritative to be "off", then it will DECLINE authentication and let other modules handle it when the user returns from the redirect without a valid credential. This can happen if the central login server is down or the user didn't actually login at the central login server. The DECLINE will also occur if the user is unauthorized for any reason.