Oracle Utilities Opower Energy Efficiency Web Portal - Classic Single Sign-On

Transcription

1 Oracle Utilities Opower Energy Efficiency Web Portal - Classic Single Sign-On Configuration Guide E Last Update: Monday, October 09, 2017

2 Oracle Utilities Opower Energy Efficiency Web Portal - Classic Single Sign-On Configuration Guide E Copyright 2012, 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency- specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of thirdparty content, products, or services, except as set forth in an applicable agreement between you and Oracle. Documentation Accessibility For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at Access to Oracle Support Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit or visit if you are hearing impaired. ii

3 Contents Introduction... 1 Utility Checklist... 1 General SAML Requirements... 1 SAML Version... 1 SAML Roles... 2 Supported SSO Profiles... 2 SAML Bindings... 2 Identity Provider to Service Provider Binding... 2 Service Provider to Identity Provider Binding... 3 SAML Assertion Requirements... 3 RelayState... 3 SAML Data Elements... 4 SAML Subject... 4 SAML Attribute... 4 Security... 4 User Experience... 5 Visiting Utility Website First... 5 Visiting Energy Efficiency Web Portal - Classic First... 5 Accessing Multiple Accounts for a User... 6 Embedding Oracle Utilities Opower Widgets on a Utility Website... 6 SAML Configuration Information... 6 Oracle Utilities Opower SAML Information... 6 Production Information... 6 Staging Information... 7 Information Required by Oracle Utilities from the Client... 7 Testing Procedures... 7 Appendix: XML Schema... 8 iii

4 Introduction This document contains the requirements for implementing single sign-on (SSO) with the Oracle Utilities Opower Energy Efficiency Web Portal - Classic. SSO makes it easier for customers to access their energy usage by allowing them to use their utility web application username and password to access the Energy Efficiency Web Portal - Classic. Note: While this document refers to the Energy Efficiency Web Portal Classic, the SSO configuration information also applies to the Digital Self Service - Energy Management Web Portal except where explicitly noted. For more information, see the Oracle Utilities Opower Digital Self Service Energy Management Cloud Service Product Overview. With SSO, customers can log into the utility website and navigate to the Energy Efficiency Web Portal - Classic without creating an additional account or going through a separate authentication process. If customers attempt to access the Energy Efficiency Web Portal - Classic and are not currently logged into the utility website, they will be automatically directed to the utility website to sign in and returned to the Energy Efficiency Web Portal - Classic page they were trying to view. SSO relies on standards-based communication between a Federation server managed by the utility and one managed by Oracle Utilities. Utility Checklist This document explains the following utility requirements: Set up two SAML 2.0 Identity Provider Federated servers: Stage and Production. Set up authentication services: Stage and Production. Provide Oracle Utilities with SAML metadata to connect to these servers. Provide Oracle Utilities with test login accounts for end-to-end testing on these servers. If needed, provide Oracle Utilities with VPN access to Stage login page. General SAML Requirements SAML Version Oracle Utilities supports Security Assertion Markup Language (SAML) 2.0 to implement SSO with clients. SAML 2.0 is the latest version of SAML and provides a rich and robust feature set. SAML 2.0 was ratified by the OASIS Standard in March 2005 and many software vendors have stable products that support SAML 2.0. SAML 2.0 has more features and is easier to implement than SAML 1.1. Oracle Utilities does not currently support SAML 1.1. OASIS, the standards organization behind SAML, is currently not planning new versions of the SAML standard. If new versions are announced, Oracle 1

5 Utilities will work to incorporate support for the last SAML versions in our product offering. SAML Roles Oracle Utilities will act as the Service Provider (SP) and the utility will act as the Identity Provider (IdP). This means that consumers will log in on the utility website using their username and password for the utility website. Consumers can then access the Energy Efficiency Web Portal - Classic without having to log in again. Supported SSO Profiles For further information on SAML SSO Profiles, please see Oracle Utilities requires Service Provider (SP)-initiated SSO. SP-initiated SSO allows users to bookmark pages on the Energy Efficiency Web Portal - Classic. Also, if an Oracle Utilities session expires while a user still has a window open, SP-initiated SSO will allow them to log in again and automatically return to the resource they requested. Performing SP-initiated SSO requires that the client have a functional SSO URL that Oracle Utilities can access to begin the SSO process. Oracle Utilities also supports Identity Provider (IdP)-initiated SSO for the Energy Efficiency Web Portal - Classic. Clients must send Oracle Utilities a valid URL as a RelayState parameter. Oracle Utilities will provide the clients with appropriate URL for the Energy Efficiency Web Portal - Classic Dashboard, which should be used as the default RelayState parameter. Clients may also create links that take users to specific pages on the Energy Efficiency Web Portal - Classic (such as the Data Browser or My Energy Use section) by passing these URLs in the SAML RelayState parameter. Warning: The Digital Self Service Energy Management widgets require SP-initiated SSO. Whether a user attempts to access the Energy Efficiency Web Portal - Classic using IdP-initiated or SP-initiated SSO, clients must ensure that their Federation server only authenticates users that have permission to access the Energy Efficiency Web Portal - Classic. Oracle Utilities does not perform additional validation. SAML Bindings Identity Provider to Service Provider Binding Oracle Utilities accepts SAML assertions from Identity Providers using the HTTP POST binding method. This means all SAML assertions are sent as HTTP POST requests to the Oracle Utilities Federation server. The SAML specification also allows assertions to be sent using HTTP artifact binding, which requires direct server to server communication and is more complex to configure. Oracle Utilities has found it is 2

6 preferable to use HTTP POST and have the browser transmit the SAML assertion to the Oracle Utilities Federation server. For this reason, Oracle Utilities does not support artifact binding for SAML 2.0. Note: Ensure that X-Frame-Options HTTP response header is excluded from the HTTP response. This requirement allows content to be embedded using iframes, which includes Oracle Utilities Opower embeddable widgets. Service Provider to Identity Provider Binding Oracle Utilities supports either HTTP redirect binding, or HTTP POST binding when sending authentication requests to the Identity Provider. By default, Oracle Utilities will use HTTP redirect binding. This means that when Oracle Utilities begins the SP-initiated SSO process, Oracle Utilities will issue an HTTP redirect to the user s browser directing them to the Identity Provider. The Identity Provider Federation service will then receive an HTTP GET request from the consumer and initiate the authorization process. For similar reasons as above, Oracle Utilities does not support artifact binding on communication from Oracle Utilities to the Identity Provider. SAML Assertion Requirements RelayState Identity Providers must send Oracle Utilities a RelayState parameter in the SAML assertion sent to Oracle Utilities. In IdP-initiated SSO, clients can set up links that will take users directly to any page they wish by sending the appropriate URL in the RelayState. Oracle Utilities will provide clients with our Dashboard URL to be used as a default RelayState parameter. The Dashboard is an appropriate general page to send customers to once they log in. Clients must provide this Dashboard URL or another valid URL as the RelayState URL when using IdP-initiated SSO. In SP-initiated SSO, if Oracle Utilities sends a RelayState parameter to the Identity Provider, the Identity Provider must send the RelayState parameter back to Oracle Utilities without any modifications, as stated in the SAML 2.0 specification. When Oracle Utilities sends a RelayState parameter in SP-initiated SSO, it will be an alpha-numeric token that refers to saved state information on the Oracle Utilities federation server, and the RelayState will not be a URL. In some instances of SP-initiated SSO, Oracle Utilities will not send a RelayState parameter. For example, this occurs when the user clicks on the Sign In link on the Energy Efficiency Web Portal - Classic home page. In these situations, the Identity Provider should use the Dashboard URL or other suitable Energy Efficiency Web Portal - Classic URL for the RelayState. 3

7 SAML Data Elements SAML Subject The SAML subject must contain a user identifier. Oracle Utilities will describe the exact value required for this field based on the implementation plan. It will be one or more of the fields passed in the historical and iterative data files about the particular customer. Oracle Utilities will use this identifier to determine which account to display to the customer. SAML Attribute A SAML attribute can provide additional attributes that are associated with a particular customer. The name of the attribute must be userdataxml and must have <sso_user_properties> as its value. For example, the attribute may contain a <property> tag that specifies customer preferences or characteristics, such as a preferred language. <saml:attributestatement xmlns:xs=" <saml:attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrnameformat:basic" Name="userDataXML"> <saml:attributevalue xsi:type="xs:string" xmlns:xsi=" version="1.0" encoding="utf-8"?> <sso_user_properties> <property> <name>language_preference</name> <value>zh_hk</value> </property> </sso_user_properties> ]]</saml:attributevalue> </saml:attribute> </saml:attributestatement> Note: The language preference specification is optional and only applicable to utilities that allow their customers to view the Energy Efficiency Web Portal - Classic in different languages. See the Oracle Utilities Opower Multiple Language Support Configuration Brief for more information. See Appendix: XML Schema on page 8 for more information. Security Security for SAML is done through several mechanisms. First, SAML assertions sent using POST binding from the Identity Provider must be digitally signed with the Identity Provider s private key using XML signature. This is a requirement per the SAML specifications. Oracle Utilities will then verify the source with the corresponding public key. Assertions that fail this verification process will be rejected. This mechanism ensures that only assertions originating from the proper utility client are accepted. Furthermore, data is encrypted via HTTPS during transfer. In addition, the RelayState parameter does not include a full URL when it is passed from Oracle Utilities 4

8 to the client and then back, but it is a reference to the desired URL which is stored on the Oracle Utilities Federation server. This prevents unauthorized parties from tampering with the destination URL during transit. User Experience The user experience can be customized when implementing SAML SSO by controlling how the utility website initiates SSO and how users are directed to the Oracle Utilities website from the Oracle Utilities Opower Home Energy Reports (HERs). Some of the most widely used options are described below. The URL on the HERs can point directly to the Energy Efficiency Web Portal - Classic or the utility website. Visiting Utility Website First In this scenario, the URL on the HERs points users directly to the utility website. After users log in, they can be presented with links that would take them to the Energy Efficiency Web Portal - Classic using SSO. These links can be customized to link to any particular page on the Energy Efficiency Web Portal - Classic. The disadvantage of this approach is that the user may never navigate to the Energy Efficiency Web Portal - Classic and only conduct other activities (like bill pay) based on the functionality of the existing utility website. Another option is for the URL on the HERs to take the user directly to a landing page on the Utility website that is specific for the Oracle Utilities Opower program. Users would be directed to the Energy Efficiency Web Portal - Classic using SSO after they log in. The advantage of this technique over using the overall utility homepage on the HER is that users accessing the website on the HER URL are taken directly to the Energy Efficiency Web Portal - Classic after logging in which will maximize use of the Energy Efficiency Web Portal - Classic. Users can still go the main utility website for other necessary functions and applications, such as paying bills. Both these options use IdP-initiated SSO. The disadvantage of these options is that users cannot browse content on the Energy Efficiency Web Portal - Classic prior to logging in. Visiting Energy Efficiency Web Portal - Classic First Another option is for the Home Energy Report (HER) URL to take the user directly to the Energy Efficiency Web Portal - Classic. Consumers can then browse content that is available to non-logged in users. If users click on a link that requires that they be logged in to view the content, they are directed to the utility website to log in under SP-initiated SSO. After logging in, they are directed back to the Energy Efficiency Web Portal - Classic to the specific page they were trying to access. The Energy Efficiency Web Portal - Classic home page also presents the user with links allowing them to sign in or register. The default configuration is to have these links invoke SP-initiated SSO and have the user directed back to the Energy Efficiency Web 5

9 Portal - Classic home page after they complete the sign in process. The utility can elect to send the user to any arbitrary page on the Energy Efficiency Web Portal - Classic. These links can be configured to point to any specific URL on the utility (or any other website). If the method described above is used, customers can browse content on the Energy Efficiency Web Portal - Classic that is accessible for users that are not logged in. The advantage of having the HERs contain the URL of the Energy Efficiency Web Portal - Classic is that this ensures users will land on the Energy Efficiency Web Portal - Classic after logging in. Accessing Multiple Accounts for a User The Energy Efficiency Web Portal - Classic currently supports displaying information for one particular Utility Account for a particular user session. This means that Oracle Utilities can display information on electricity and/or gas usage for one premise at a given time. Some utilities allow a customer who may have accounts for multiple properties to access all of these from the utility website. For these scenarios, the utility should use IdP-initiated SSO and create links to Oracle Utilities when the user is on a page for a specific account on the utility website. For example, when the user is viewing billing information for a particular account, they could be presented with a link to the Energy Efficiency Web Portal - Classic for that account. They can then view the specific information on the Energy Efficiency Web Portal - Classic and access information for other accounts as necessary. Embedding Oracle Utilities Opower Widgets on a Utility Website The Oracle Utilities Opower Digital Self Service Energy Management widgets can be embedded on a utility s website. Oracle Utilities requires configuring SP-initiated SSO to present a consistent view of the customer s data on the utility website and all embedded widgets. See Identity Provider to Service Provider Binding on page 2 for information on HTTP response requirements for embedded widgets. SAML Configuration Information When implementing SSO, most clients choose to contract with a federation server provider and configure settings through the provider s interface. Configuration details are provided below. Oracle Utilities Opower SAML Information Production Information Oracle Utilities Opower SAML Entity ID: sso.opower.com Oracle Utilities Opower Assertion Consumer Service URL: 6

10 Default Target URL (RelayState Value): To be provided by Oracle Utilities. Staging Information Oracle Utilities Opower SAML Entity ID: sso-stage.opower.com Oracle Utilities Opower Assertion Consumer Service URL: Default Target URL (RelayState Value): To be provided by Oracle Utilities. Information Required by Oracle Utilities from the Client Client SAML Entity ID: Same concept as the Oracle Utilities Opower entity ID. Client Public Key: Oracle Utilities requires the public key for the corresponding private key the utility is using to sign their SAML assertions. SAML requires the Identity Provider to sign all assertions submitted via POST with a private key. Oracle Utilities need the public keys to verify the assertions were sent by the utility client. SAML Single Sign-On Service URL: Required for SP-initiated SSO. SPinitiated SSO is where the user visits the URL for the Energy Efficiency Web Portal - Classic before logging in at the client utility website. Oracle Utilities needs to redirect users to the utility to begin the sign in process and afterwards they will be returned to the URL on the Energy Efficiency Web Portal - Classic they were trying to access. This is done by sending SAML messages to the partner s Federation server to begin a user's SSO process. This value is the URL Oracle Utilities will use to begin SP-initiated SSO. Oracle Utilities uses redirect binding to access this URL. Logout Redirect URL: This is an optional parameter. It is the URL Oracle Utilities will redirect the user to after they click the Logout link. Testing Procedures SSO implementations are thoroughly tested by the client and Oracle Utilities before going live. Oracle Utilities has separate instances of our consumer Web Portal and Federation server specifically for integration testing. This is known as our Staging Environment. This infrastructure is completely separate from the production Oracle Utilities infrastructure. Before going live with a client, the Oracle Utilities staging infrastructure is configured to accept SAML assertions from the corresponding utility testing environment. The utility application and Federation server must similarly be configured to send SAML assertions to the Oracle Utilities Federation server. In order to verify a successful connection and assist with troubleshooting, Oracle Utilities needs the ability to login on the utility s Stage environment. This may require VPN access if the utility stage environment is located behind a firewall. It will also require at least one valid login on the utility s stage environment. 7

11 Once testing is complete, the configurations are migrated to the production applications for both Oracle Utilities and the utility. To verify these connections, Oracle Utilities also needs a test account on production. The stage and production test accounts should be available for the life of the program for continuous verification of end-to-end SSO functionality. Appendix: XML Schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" id="sso_user_properties" elementformdefault="qualified" version="v0.1.0"> <xs:annotation> <xs:documentation xml:lang="en"> </xs:documentation> </xs:annotation> <xs:element name="property"> <xs:annotation> <xs:documentation xml:lang="en"> An arbitrary property. </xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="name" type="xs:string" minoccurs="1" maxoccurs="1"/> <xs:element name="value" type="xs:string" minoccurs="1" maxoccurs="1"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="error" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="en"> If there was a problem providing a valid response, this should be set to contain an explanation of the problem. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="sso_user_properties"> <xs:annotation> <xs:documentation xml:lang="en"> Root element. </xs:documentation> </xs:annotation> <xs:complextype> <xs:choice> <xs:sequence> <xs:element ref="property" minoccurs="1" maxoccurs="unbounded"/> </xs:sequence> <xs:element ref="error" /> </xs:choice> 8

12 </xs:complextype> </xs:element> </xs:schema> 9