Page Comparison

...

WebproxyPortlet v2 Gateway SSO is a feature that allows uPortal to signon to any remote system even if the remote system does not share any authentication information with uPortal.  Gateway SSO will submit login information to the remote system and then redirect to that remote system.  Other SSO solution assume that uPortal has authenticated to some system, such as CAS and will then trust CAS to say the user is authenticated.  In this system, the authentication information is submitted to the remote system invisible to the user.  This solution has the inherent risks of sending user authentication information over the wire, rather than a security token, but this solution does not require external systems to implement CAS or another authentication system.  It is therefore nearly invisible to any external system to which uPortal would want to connect.

Image Added

Workflow

The workflow for accessing an external system through Gateway SSO is as follows (assuming that the portlet is configured and will be rendered on the user's page):

...

1. The user clicks on the link for the external system they wish to access.  By default this opens a new tab that returns a page with a Javascript AJAX handler to request connection information from the handling controller, but there is a portlet preference to replace the existing page. 
2. The handling controller gathers all of the information stored in the HttpContentRequestImpl parameters configuration (basically a list of form fields and values) and readies them for return to the browser
3. All configured Interceptors perform any substitutions on configuration data, such as inserting usernames and passwords.
4. All configured IAuthenticationFormModifier modules run.  These can add additional parameter fields to the result and may perform additional custom logic (depending upon the implementation).  An example of an IAuthenticationFormModifier is a need to contact an external system to get a token that is submitted with the authentication form to the external system.  The custom logic can invoke the external system, parse out the token, and add it as a form field or modify the submit URL to include the token.
5. If the GatewayEntry is flagged as requiring a secure URL (default true), the URL (proxiedLocation) is checked and altered to /HTTPSUrlRequiredButNotSpecified if it was not secure.
6. The controller returns all of the gathered data to the browser (by default a JSON response with caching disabled).
7. The Javascript Ajax handler builds an appropriate html form and submits it to the external system.  As part of this processing, any custom javascript files that are specified for the entry are also executed.  The external system then handles the call and will render whatever page a successful login would render.

...

In theory each GatewayEntry could have multiple HttpContentRequestImpl records associated with it; in practice, each GatewayEntry would only have one HttpContentRequestImpl record (see 

...

UserInfoUrlParameterizingPreInterceptor

UserPreferencePreInterceptor UserInfoUrlParameterizingPreInterceptor overrides FormFieldImpl values with the values stored in UserInfo.  uPortal can be configured to store your uPortal login and password, making them available to userInfo.  If uPortal is configured this way (refer to the uPortal manual for exposing user attributes to a portlet), this interceptor will send the same uid and password that you used to authenticate to uPortal to the external system.  Since uPortal and the external system do not share an authentication system, it is still possible for the two systems to get out of sync.  An example of a valid FormFieldImpl value would be "{user.login.id}"

...