Updating Customer Portal Single Sign-On user information

As described previously, information about the user can be passed in during the login process via the LoginSSO web service. This is convenient and assures the user data in Itron Analytics is current when the user accesses the Customer Portal.

However, there is one downside to only passing this information during the login using the LoginSSO web service. The utility website will often provide some capability for the user to change their email address, and if this change is not immediately sent to Itron Analytics, the user alert emails generated by the Customer Portal will be sent to the old email address. Likewise, if the utility removes a user’s access to an account, the user will still continue to receive alerts related to usage under the account. This would continue to happen until the user logged in to the utility website and navigated to the Customer Portal.

You can use the UpdateSSOUser web service to mitigate this problem. This web service can be called at any time to update a Customer Portal Single Sign-On user’s information in Itron Analytics. The single sign-on update UpdateSSOUser workflow is nearly the same as the LoginSSO workflow, with the following differences:

  1. UpdateSSOUser is a REST web service in Customer Portal at http://localhost/PortalServices/api/User/UpdateSSOUser.

  2. All parameters sent to the service are the same. The application-level user must be created for Basic Authentication of the service, and the JSON values (including username, account ID list, etc.) are also the same.

  3. The service will validate the username first and create it if it does not exist with the JSON values sent. If it does exist, the service will compare values sent in the JSON with those existing in the database and overwrite the database with any changes.

  4. The web service does not create or return a session token, it only returns a status of 200 when the update has been successful and error messages otherwise. There is no way to log a user in using this service; that can only be done through LoginSSO.

  5. There is no need to create a POST/GET redirect to the Customer Portal when the service is finished, because no token is created or returned.

In this way, the utility website can make web service calls to keep email, first name, last name and account list updated in the Customer Portal database for a corresponding SSO user without that user having to log in. SSO users can also be created in Customer Portal if they do not already exist using this same method.