There is a different set of actors in a proxied WIND login than in a standard login. In addition to the user and the WIND server, there are also the proxying application and the proxy target (or target application). The proxying application is the application to which the user logs in, for example, a portal. The proxy target is the application for which the proxying application requests a ticket on the user's behalf.
The proxy target is identical to the destination site in the standard login, except that in a proxied login there is no initial connection attempt without a ticket. The proxy will be issued a ticket before attempting to contact the target application, so no redirection is necessary. The target app only needs to validate the ticket that it is presented.
The proxying application plays two different roles at different times in the login sequence. Its first role is that of a target application in a standard login, where it requires the user to login, then validates the ticket that it is presented. Once it has established a session with the user, it then becomes a proxy, acting on behalf of the user to log in to other applications.
The initial sequence of events is similar to a basic authentication: the user attempts to log in to the destination site without a ticket and is redirected to WIND. After a successful login, the user is forwarded to the destination with a ticket.
The validation request is the same as before, but an additional parameter is included to indicate that a Proxy Granting Ticket (PGT) is desired. If the ticket is valid, WIND will include a PGT in its response. Thereafter, when the application needs to login to another app, it sends a request for a Proxy Ticket (PT) with the PGT as a parameter. WIND will then issue a PT that can be presented to the target application as if it were a standard ticket.
This diagram summarizes the sequence of events which occurs during a successful standard WIND authentication:
Web browser user makes an initial attempt to connect to the portal, without presenting a valid login ticket.
The Authentication request. The destination redirects the user to the WIND Login URI. An extra parameter included in the request indicates where the user should be redirected after successful authentication.
After a successful login, the user is redirected back to the specified destination URI. This time, a valid single-use authentication ticket is included as a parameter.
The Validation Request. The destination site sends a request to the WIND server to validate the authentication ticket being presented, and includes a parameter requesting a Proxy Granting Ticket (PGT).
The application establishes a session for the user after the ticket is validated.
During a proxied login, when a portal or other application wants to obtain proxy tickets on behalf of a user, the initial sequence is the same as above (but with the extra parameter in the validation request). This is followed by the additional steps detailed in the diagram below:
As above.
As above.
As above.
The Validation Request. The destination site sends a request to the WIND server to validate the authentication ticket being presented, and includes a parameter requesting a Proxy Granting Ticket (PGT).
Not applicable.
The WIND server sends back a Yes/No response. As with a basic login, tickets are "single-use": the WIND server will only return Yes once for a given ticket. If the ticket is valid and the application is authorized to receive PGTs, the response will be Yes and include a PGT.
The application sends a request to the WIND server for a Proxy Ticket (PT) in order to login to another service, including the PGT as a parameter.
If the PGT is valid and the target service has agreed to accept PTs, WIND will respond with a PT that the application can then present to the target application. Proxy Tickets, like standard tickets, are "single-use".
The PT Validation Request. The target application sends a request to the WIND server to validate the Proxy Ticket being presented.
The WIND server sends back a Yes/No response. If the ticket is valid, the response will include an indication that the ticket has been proxied, as well as the name of the proxying service that.
The target application can then make its own access-control decision based on the identity of the user and of the proxying application.
The application can repeat the PT request process as long as the PGT remains valid in order to connect to other applications.