New User Registration Framework and Delegated Access

The New User Registration framework, when you integrate it with Delegated Access, enables the proxy to register and authenticate to your system and provides an easy way to transfer the proxy directly to the initial page to start the process of viewing or updating somebody else’s data. The framework provides a sample New User Registration login page that you can customize and deploy to suit your institution’s requirements. A proxy can use this page to sign into the system using an existing user ID or to register for a new user ID. A suggested approach to allow the proxy to access the New User Registration login page (or your own sign in page) is by including a URL in the email notification sent to the proxy when the delegator creates the proxy and delegates some transactions. The URL is used to transfer the proxy to the login page. The URL must be embedded with the location of your login page, New User Registration Gatekeeper information, and optionally, but recommended, the NUR context ID value that is delivered for Delegated Access.

After signing into your system, the very first thing a new proxy must do to start reviewing the delegator’s data is to accept the terms and conditions, which proves that the proxy will act responsibly with the delegator’s data. This is done in the Proxy Terms and Conditions page. Integrating Delegated Access with New User Registration offers a seamless way of automatically provisioning the proxy with the security to access this page and then to transfer the proxy to this page immediately after successfully authenticating to your system. The New User Registration Context functionality allows you to do just that. The delivered New User Registration context ID specific to Delegated Access (SCC_NURCTXT_20120918102441 (NUR_DELEGATED_ACCESS) must be embedded in the URL the proxies use to access your New User Registration login page. This is also the URL that is programmatically inserted in the email message sent to the proxies. This URL replaces the Access URL variable in the DA_PROXY_GRANT generic email template. The context ID is used in the Delegated Access application class SCC_DA.NOTIFICATION.NOTIFY. There are two types of URL the application class can include in the generic email template: the URL that serves for testing your deployment of Delegated Access with New User Registration (Tester URL), or the URL used for when your deployment of Delegated Access is ready to be in production (Production URL). The application class selects the URL that you mark as Active, and uses it to replace the Access URL variable that is defined in the DA_PROXY_GRANT generic email template.

Note: A known proxy (proxy that has already accepted the terms and conditions for accessing a specific delegator’s data and therefore programmatically associated to that delegator), should not see the Proxy Terms and Conditions page again. Therefore, when additional transactions are delegated to a known proxy, a URL could be inserted inside the information email template (DA_KNOWN_PROXY_GRANT) without being embedded with a New User Registration Context ID. In that case the proxy is transferred to your home application page after successfully signing into your system.

The NUR context ID can be set as follows:

This example illustrates a New User Registration Context ID created for Delegated Access where the Production URL is Active.

Example: New User Registration Context ID created for Delegated Access where the Production URL is Active

The system adds the Role Name you select to the proxy’s user profile just-in-time after the proxy successfully goes through registration and authentication from the New User Registration login page (or your custom version of it). Make sure the selected roles grant access to the page defined in the Target Page group box. In the case of Delegated Access, the target page is the Proxy Terms and Conditions. In the sample screenshot, the defined target page transfers the proxy directly to the Proxy Terms and Conditions. The proxy’s first action is to accept or decline the terms and conditions for accessing the data that belongs to someone else. Setting a target page facilitates the user experience for the proxy because the proxy does not need to manually navigate to the target page.

The following sample roles are delivered with your system, which show examples of how you can grant access to the Proxy Terms and Conditions page.

  • CS – DA Proxy TermsConditions

    This is the Role selected inside the delivered New User Registration Context ID shown above. It grants access to the Proxy Terms and Conditions page without menu navigation (the permission list contained inside the role does not allow a user to navigate to the page). The page can only be accessed after being successfully authenticated by New User Registration. This setup is recommended to avoid having a proxy re-accessing the Proxy Terms and Conditions page by mistake.

  • CS – DA Proxy TermsCond_Test

    Use this role for testing only. It grants the proxy access to the Proxy Terms and Conditions page, but with menu navigation: Self – Service > Proxy Terms and Conditions. This is not a real implementation option, but you can use this role to help your administrators test the functionality without setting up the New User Registration framework, or your own solution to authenticate a proxy to your system.

The URL that is embedded in the email notification a new proxy receives is the context specific URL you mark as Active. If you want to test the Delegated Access process without setting up a Kiosk or portal environment, set the Tester URL as the active URL. The Tester URL transfers the proxy to the NUR Tester login page. When you are ready to deploy your application, set the Production URL as Active to transfer the proxy to your real login page, which is either the NUR sample login page or your custom version of the page. The Production and Tester URLs that appear on the New User Registration Context Setup page are based on the generic URLs you set up in the New User Registration Installation page, combined with the NUR context ID. If you prefer to manually enter a URL, then on the New User Registration Context Setup page, select Customize URL and make sure you select this URL to be active. This is especially useful if you do not use the NUR framework for your security needs. If you use a customized URL, you do not need to modify the Delegated Access application class (SCC_DA.NOTIFICATION.NOTIFY) because it uses the URL you set as active regardless of whether it is automatically generated or customized.

Note: If the proxy already has a user ID to access the Campus Solutions database (for example, the proxy is an alumnus or an employee at your institution), then the proxy can reuse his or her existing user ID to access the delegator’s data. The same is true if multiple delegators delegated access to the same proxy. The proxy can reuse the same user ID to access all of the delegator’s data. This meets the security convention that ideally one person has one user ID to access a system. The role provisioning and the target page transfer occur regardless of whether the user ID is newly created or if an existing one was used.

See Setting Up New User Registration Context.