html5-img
1 / 98

Technical Communications Workshop

Technical Communications Workshop. September 03, 2008. Antitrust Admonition. ANTITRUST ADMONITION

trent
Télécharger la présentation

Technical Communications Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Technical Communications Workshop September 03, 2008 http://nodal.ercot.com 1

  2. Antitrust Admonition ANTITRUST ADMONITION ERCOT strictly prohibits Market Participants and their employees who are participating in ERCOT activities from using their participation in ERCOT activities as a forum for engaging in practices or communications that violate the antitrust laws. The ERCOT Board has approved guidelines for members of ERCOT Committees, Subcommittees and Working Groups to be reviewed and followed by each Market Participant attending ERCOT meetings. If you have not received a copy of these Guidelines, copies are available at the Client Relations desk. Please remember your ongoing obligation to comply with all applicable laws, including the antitrust laws. http://nodal.ercot.com 2

  3. Workshop Agenda • Antitrust Admonition 0900 – 0910 • API Sub Group Topics 0910 – 0930 • Introduction • Overview of Agenda • API Sub Group Topics • WSDL / XSD Overview 0930 - 1015 • WSDL / XSD Overview • Basic Message Structures • EIS Specification • ERCOT WSS Security • <break> 1015 – 1030 • Setting Up a client 1030 – 1145 • Java Example • .NET Example http://nodal.ercot.com 3

  4. Workshop Agenda • Break for Lunch (on site) 1145 – 1230 • Setting up a Listener 1230 – 1300 • Maintenance 1300 – 1320 • Management of Certificates • Participant Requested Topics 1320 - 1400 • Trades Workflow (high level) • Alerts and Notifications • Data Review • ERCOT WAN (high level) • Follow-up items From Original Workshop Held on 9/3/08 http://nodal.ercot.com 4

  5. API Sub Group Topics • To better serve the needs of the market, we are implementing several changes: • Focus the API Subgroup on technical, developer-to-developer issues • Direct discussions about data, report and extracts, and releases to the EDS team • Track communications at the program level • Rationale for these changes: • The EDS team is the source of truth for Nodal schedules and is equipped to manage market questions and responses • The old process was blurring the line between functional and technical • Functional is the “what” and includes data elements, rules, structures, and formats • Technical is the “how” and includes delivery mechanisms, authentication/authorization, and performance • What next: • The Friday EDS calls will include the EIP update • We will maintain the Google Group until a better solution is available • We are working with ERCOT to develop a long term process and site to better communicate this information to the market http://nodal.ercot.com 5

  6. WSDL / XSD Overview http://nodal.ercot.com 6

  7. WSDL / XSD Overview – Supporting Documentation • Enterprise Interface Specification Document • http://nodal.ercot.com/readiness/sandbox/websvc/index.html • WSDL & XSD Package • http://nodal.ercot.com/readiness/sandbox/documents/index.html • Nodal.wsdl • Describes external web services. Specifies location of service and the operations exposed by the service. • XSDs • Defines the structure of the messages http://nodal.ercot.com 7

  8. WSDL / XSD Overview – Implementation Approach • Define Web services needed for Market Participants to request market information and initiate transactions • Leverage IEC 61968 for definition of message • Use the IEC Common Information Model (CIM) where appropriate • Loosely coupled flexible design • Provide the means for Market Participant Systems to receive notification messages from ERCOT systems • Leverage OASIS WS-Notifications specification • Participants will have notifications pushed to their listener http://nodal.ercot.com 8

  9. WSDL / XSD Overview – Application of IEC 61968 to Web Services • Message structures based upon IEC 61968-1 defined for the input and output of operations (i.e. request and response) • Header used for information needed for all messages, includes key control information such as verb, noun and source • Request structure has parameters (some required, some optional) that are appropriate for the specific operation • Reply structure indicates success, failure and errors as appropriate • Payloads can be strongly typed or loosely coupled from message structures, where payloads can be compressed and encoded if needed • Messages form the body of the underlying SOAP message http://nodal.ercot.com 9

  10. WSDL / XSD Overview – Web Service Message Payloads • Message payloads carry the data that is needed for a specific request or reply • The noun in the message header identifies the type of the payload • Payloads can be supplied in one of the following forms: • Any type of XML element of any namespace (with structure typically defined by an XSD) • An XML document that is encoded as a string, compressed and base64 encoded • Other base64 encoded content http://nodal.ercot.com 10

  11. WSDL / XSD Overview – WSDL Overview Nodal.wsdl (WSDL Design View in XMLSpy) http://nodal.ercot.com 11

  12. WSDL / XSD Overview – WSDL Overview – Verbs/Nouns Nodal.wsdl – Web Services http://nodal.ercot.com 12

  13. WSDL / XSD Overview – ERCOT XML Schema files http://nodal.ercot.com 13

  14. WSDL / XSD Overview – XSD Overview http://nodal.ercot.com 14

  15. Basic Message Structure – message.xsd • All messages exchanged between MP and ERCOT webservices use pre-defined structure for requests and responses. • Messages are constructed with several sections • Header • Request (Valid for RequestMessage) • Reply (Valid for ResponseMessage) • Payload http://nodal.ercot.com 15

  16. Basic Message Structure – Message Header Structure • Header is required in all messages exchanged between MP and ERCOT Web Services. http://nodal.ercot.com 16

  17. Basic Message Structure – Message Request Structure • ‘Request’ is required to be populated in the Request Xml, depending on the type of transaction submitted (Example: Queries [Verb: get Noun: BidSet]). http://nodal.ercot.com 17

  18. Basic Message Structure – Message Reply Structure • Used in Response to indicate success, failure and error details. http://nodal.ercot.com 18

  19. Basic Message Structure – Message Payload Structure • Payload is required depending on the type of transaction that’s being submitted. • Payload XML needs to conform to the ERCOT XSDs http://nodal.ercot.com 19

  20. Basic Message Structure – Example BidSet Sequence Diagram http://nodal.ercot.com 20

  21. EIS Specification - Role of EIS Specification • You’ll need, the WS Contract + EIS to interact with ERCOT Web Services: + http://nodal.ercot.com 21

  22. EIS Specification - Role of EIS Specification – Cont. Yields: <BidSet xmlns="http://www.ercot.com/schema/2007-06/nodal/ews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ercot.com/schema/2007-06/nodal/ews ErcotTransactions.xsd"> <tradingDate>2008-01-01</tradingDate> <OutputSchedule> <startTime>2008-01-01T00:00:00-05:00</startTime> <endTime>2008-01-02T00:00:00-05:00</endTime> <marketType>DAM</marketType> <resource>SANDHSYD_SH2</resource> <deleteTPOs>true</deleteTPOs> <EnergySchedule> <startTime>2008-01-01T00:00:00-05:00</startTime> <endTime>2008-01-02T00:00:00-05:00</endTime> <TmPoint> <time>2008-01-01T00:00:00-05:00</time> <ending>2008-01-02T00:00:00-05:00</ending> <value1>20</value1> <value2>20</value2> <value3>20</value3> </TmPoint> </EnergySchedule> </OutputSchedule> </BidSet> http://nodal.ercot.com 22

  23. <?xml version = "1.0" encoding = "UTF-8"?> <inputMessage> <ns0:RequestMessage xmlns:ns0 = "http://www.ercot.com/schema/2007-06/nodal/ews/message"> <ns0:Header> <ns0:Verb>create</ns0:Verb> <ns0:Noun>BidSet</ns0:Noun> <ns0:ReplayDetection> <ns0:Nonce>39b2fa420b9766e06a302ccef0531e7e</ns0:Nonce> <ns0:Created>2008-08-27T17:20:51.65-05:00</ns0:Created> </ns0:ReplayDetection> <ns0:Revision>1.0</ns0:Revision> <ns0:Source>TEST_LOOPBACK_MBALUSA</ns0:Source> <ns0:UserID>NODALTEST</ns0:UserID> <ns0:MessageID>MBALUSA_TEST</ns0:MessageID> </ns0:Header> <ns0:Payload> <BidSet xmlns = "http://www.ercot.com/schema/2007-06/nodal/ews" xmlns:xsi = ErcotTransactions.xsd"> <tradingDate>2007-11-30</tradingDate> <status>Open</status> <mode>Normal</mode> <COP> <startTime>2007-11-30T00:00:00-06:00</startTime> <endTime>2007-11-30T00:00:00-06:00</endTime> <resource>PBSES_UNIT5</resource> <ResourceStatus> <startTime>2007-11-30T00:00:00-06:00</startTime> <endTime>2007-11-30T23:00:00-06:00</endTime> <operatingMode>ON</operatingMode> </ResourceStatus> <Limits> <startTime>2007-11-30T00:00:00-06:00</startTime> <endTime>2007-11-30T23:00:00-06:00</endTime> <hsl>70.25</hsl> <lsl>7</lsl> <hel>80</hel> <lel>10</lel> </Limits> <ASCapacity> <startTime>2007-11-30T00:00:00-06:00</startTime> <endTime>2007-11-30T23:00:00-06:00</endTime> <regUp>0</regUp> <regDown>0</regDown> <rrs>0</rrs> <nonSpin>0</nonSpin> </ASCapacity> </COP> </BidSet> </ns0:Payload> </ns0:RequestMessage> </inputMessage> Input Request Message http://nodal.ercot.com 23

  24. <?xml version = "1.0" encoding = "UTF-8"?> <outputMessage> <ns0:ResponseMessage xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns0 = "http://www.ercot.com/schema/2007-06/nodal/ews/message" xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ns0:Header> <ns0:Verb>reply</ns0:Verb> <ns0:Noun>BidSet</ns0:Noun> <ns0:ReplayDetection> <ns0:Nonce>39b2fa420b9766e06a302ccef0531e7e</ns0:Nonce> <ns0:Created>2008-08-27T17:20:51.65-05:00</ns0:Created> </ns0:ReplayDetection> <ns0:Revision>1.0</ns0:Revision> <ns0:Source>ERCOT</ns0:Source> <ns0:UserID>NODALTEST</ns0:UserID> <ns0:MessageID>MBALUSA_TEST</ns0:MessageID> </ns0:Header> <ns0:Reply> <ns0:ReplyCode>OK</ns0:ReplyCode> <ns0:Timestamp>2008-08-27T17:21:27.78-05:00</ns0:Timestamp> </ns0:Reply> <ns0:Payload> <ns1:BidSet xmlns:ns1 = "http://www.ercot.com/schema/2007-06/nodal/ews"> <ns1:tradingDate>2007-11-30</ns1:tradingDate> <ns1:status>Open</ns1:status> <ns1:mode>Normal</ns1:mode> <ns1:COP> <ns1:mRID>TEST_LOOPBACK_MBALUSA.20071130.COP.PBSES_UNIT5</ns1:mRID> <ns1:status>SUBMITTED</ns1:status> </ns1:COP> </ns1:BidSet> </ns0:Payload> </ns0:ResponseMessage> </outputMessage> Output Response Message http://nodal.ercot.com 24

  25. EIS Specification - EIS Specification Content 6.         Acknowledgement of Alerts • 7.2.1.    Close Alert 7.         Outage Scheduling Interfaces • 7.2.1.    Outage Creation • 7.2.2.    Outage Query • 7.2.3.    Outage Update • 7.2.4.    Outage Cancellation 8.         Utility Interfaces • 8.2.1.    Get mRID • 8.2.2.    System Status • 8.2.3.    Request Test Notification • 8.2.4.    Change Active Notification URL 9.         Reports • get Reports 10.        Resource Par Transactions • 10.3.1.  Generator Resource Parameters • 10.3.2.  Controllable Load Resource • 10.3.3.  Non Controllable Load Resource • 10.3.4.  Verbal Dispatch Instruction • 10.3.5.  Resource Parameters 11.        Registration Interfaces • Dispute Creation 2.         Services Organization • 2.1.       Common Message Structure • 2.2.       Common Security Implementation • 2.3.       Modeling and Conventions • 2.4.       Delivery Approach • 2.5.       Technical Interoperability • 2.6.       Service Level Agreements • … • Market Transaction Service • 3.3.1.    Three-Part Supply Offer • 3.3.2.    Self-Arranged Ancillary Service Quantities • 3.3.3.    Incremental and Decremental Energy Offer • 3.3.4.    Ancillary Service Offer • 3.3.5.    Ancillary Service Trade • 3.3.6.    Capacity Trade • 3.3.7.    Congestion Revenue Rights (CRR) Offer • … 4.         Market Information • 4.3.1.    AwardSet • 4.3.2.    AwardedAS • 4.3.3.    AwardedCRR • 4.3.4.    AwardedEnergyBid • 4.3.8.    Forecasted Load … • 4.3.9.    Real-Time System Load • 4.3.10.  Market Totals   • 4.3.11.  Market LMPs and SPPs • 4.3.12.  Market MCPCs • 4.3.13.  Binding Constraints • 4.3.14.  SCED Violated Constraints • 4.3.15.  Ancillary Service Obligation • …. 5.         Notifications • 5.3.1.    Notices and Alerts *** • 5.3.2.    Offer and Bid Set Acceptance • 5.3.3.    Offer and Bid Set Errors • 5.3.4.    Confirmed and Unconfirmed Trades • 5.3.5.    Energy Offer Awards ... • …. http://nodal.ercot.com 25

  26. EIS Specification - EIS Specification Review Upcoming Changes • EIS 1.15 • MMS MarketTransaction Interface Updates   • Market Types to ASObligations (DAM or SASM) • SubmitTime to the BidSet header holding Bid request receipt timestamp by ERCOT • Added Market type to the startup/shutdown instructions with possible values of HRUC, DRUC, and DAM • Added MarketType to the get AwardSet = DAM/ADJ/RTM/SASM/RUC/SCED • Update 3PO with SuMeFipFop and EocFipFop introduced in MMS4 • Added MultiHourBlock to CRR, PTP Oblig, Energy bid and Energy only Offer input tables • Added RRS_ NCLR as a new ASType for SelfArrangedAS • Modified CompetitiveConstraints structure to hold new elements CompetitivenessStatus, deleted OperatorOverwrite – consistent with CDR Interface • Corrected the possible values for MarketType for various Award Sets. • Updated ASOffer with nonControllableLoadFlag flag • Corrected PTP Obl. MaximumPrice/price • 3.3.2 Added RRS_NCLR to the list of ASType for SelfArrangedAS • 3.3.11  - Corrected figure 47 for EnergyOfferCurve/multiHourBlock (instead of under PriceCurve) and updated the example • MMS MarketInfo Interface Updates • BindingConstraints  - Schema • LoadDistributionFactors to have name and factor only – consistent with CDR interfaces • Merged in MIS Int Specification version  .37 - Market Info Nouns into the section 4 of this spec – 4.3.31 thru 4.3.45 • 4.3.26 Unit Availability: Tagged BlackStart and Available megawatts as a place holder for future use. • Added equipmentType to Dynamic Ratings and Dynamic Ratings Deviations • OS Interface Update • DisclaimerAck & Disclaimer as required fields for OS • Enumeration to equipment Outage, Outage states.          • 3 more cancellation reasons (EXP, ERR, and ROM) • Transmission Opportunity Outage, designatedResource - station and HSL as required per OS.xsd • Added notes about OS query StartTime and endTime are optional but they should not be present when an mRID is sent. • ResourceType choices: UL or LR • Updated Outage opportunity outages with opportunity duration – consistent with OS application • Reports • Reverted back to the original external reporting interface in section 9 – adjusted with supporting MID/MIR interface • General • Updates/added examples for all interfaces • Updated the xsd files in the appendix C http://nodal.ercot.com 26

  27. EIS Specification - EIS Specification Review Upcoming Changes (continued…) • EIS 1.16 (Sandbox Release only) • 10.0 - Added Resource Parameter Transaction Service Section • 11.0 – Added Disputes Interfaces section • EIS 1.17 on MMS 4 Patch 3 • OS Expanded Query • AS Insufficiency Report • Alerts R1 (framework only) • 1.16 Bug Fixes • EIS 1.18 on MMS5 • Policy Mgr + New WSRB • MarketInfo Services • getReports • LTLF • Alerts R2 • 1.17 Bug Fixes • EIS 1.18 on MMS5/OS Final • Chunking • Performance tuning • Bug Fixes • MMS5 Final • Alerts R3 • 1.18 Bug Fixes http://nodal.ercot.com 27

  28. ERCOT WSS Security http://nodal.ercot.com 28

  29. ERCOT WSS Security - Security Requirements • Industry good practices • Authentication • Confidentiality-protection • Integrity-protection • Prevent Replay Attacks • Access control • Auditing and logging • Consistent availability and performance • Business requirements with security implications • Design a solution that is simple and readily implementable • Use industry standards • Enable leveraging of existing security infrastructure • Provide origin authentication at the transaction level http://nodal.ercot.com 29

  30. ERCOT WSS Security - Security Standards • Transport level security via • SSL (Secure Socket Layer) / TLS (Transport Layer Security) • Message level security via signed SOAP messages according to the Web Services Security (WSS) standards http://nodal.ercot.com 30

  31. ERCOT WSS Security - Trust Model • Use Verisign Trust Network (VTN) Class 3 certificates • Provide two levels of authentication • Transport • Message • Implementations must ensure that : • Only ERCOT brand of certificate is used • Certificate has not been revoked http://nodal.ercot.com 31

  32. ERCOT WSS Security - Authentication • Transport-level • SSL/TLS is required while data travels on the Internet • Implement mutual authentication via SSL/TLS • SSL/TLS version MUST be at least 3.0 • The SSL/TLS cipher suite MUST include AES 128 bit for encryption • The SSL/TLS cipher suite MUST include SHA-1 for integrity protection • Message-level • Use OASIS Web Services Security (WSS) standards • SOAP Message Security • X.509 Token Profile • http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf • Signing entities are expected to be applications/systems with appropriate certificates http://nodal.ercot.com 32

  33. ERCOT WSS Security - Preventing Replay Attacks • Each message must include: • A timestamp as specified by WSS <wsu:timestamp> • A random number as specified by WSS <wsu:nonce> • Clocks need not be synchronized • Typical implementation • Reject expired messages • Cache the nonce for the expected amount of clock skew and reject messages whose nonce is in the cache (currently set to 5 Minutes) http://nodal.ercot.com 33

  34. ERCOT WSS Security - Implementation-Specific Security Functions • Access Control • Use authenticated identity of message producer, as determined by the signing certificate of the SOAP message • Auditing • At the SOAP message level • At the Front Gateway (Policy Manager) http://nodal.ercot.com 34

  35. ERCOT WSS Security - What does this mean to Market Participants? • Market Participants MUST • Deploy SSL/TLS • Obtain client side certificate • Certificate is issued by Verisign under the ERCOT brand • Implement mutual authentication • Ensure minimum SSL/TLS security settings • Secure SOAP messages • Obtain application/system signing certificate • Certificate is issued by Verisign under the ERCOT brand • Sign all SOAP messages • Use Web Services Security Standards and its X.509 Certificate Token Profile • Message headers MUST include a timestamp and a nonce • Validate all SOAP messages • Signature • Certificates • Revocation status of certificates • Timestamp and nonce (to prevent replay attacks) http://nodal.ercot.com 35

  36. ERCOT WSS Security - Security Summary • Web Services Client will need at most two certificates • SSL/TLS • SOAP Message Signing • Security rules are equally applicable to request, reply. • Some security functions are deployment specific and each MP must determine the best method of implementation • Implementation of industry standards promotes interoperability and flexibility http://nodal.ercot.com 36

  37. Setting Up a Client(Java) http://nodal.ercot.com 37

  38. Setting Up a Client (Java) - Supporting Software • Software used to build example java client to invoke ERCOT external web services • Java 1.5 • http://java.sun.com/javase/downloads/index_jdk5.jsp • Apache Axis 1.4 • http://ws.apache.org/axis/ • Apache WSS4J 1.5 • http://ws.apache.org/wss4j/ • Apache XML Security 1.4.1 • http://xml.apache.org/security/index.html • Apache ANT 1.7.1 • http://ant.apache.org/ • KeyTool GUI 1.7 • http://www.gria.org/downloads Disclaimer: There can be different ways to implement the client to interact with ERCOT web services using different variety of software. Associated sample java client shows one way to implement the client to interact with ERCOT’s external web services using above mentioned software. Example java client not intended for production purposes. http://nodal.ercot.com 38

  39. Setting Up a Client (Java) – Client Overview http://nodal.ercot.com 39

  40. Setting Up a Client (Java) - WSDL2Java • Apache Axis Wsdl2Java tool is used to generate stubs from Nodal.wsdl. The generated stubs will be used to invoke web services. • Command to invoke wsdl2java is • java org.apache.axis.wsdl.WSDL2Java (WSDL_FILE_PATH) • Above command generates the stubs in below packages. namespace defined in wsdl maps to java packages. • com\ercot\www\schema\_2007_06\nodal\ews\message • com\ercot\www\wsdl\_2007_06\nodal\ewsConcrete • org\w3\www\_2000\_09\xmldsig • org\oasis_open\docs\www\wss\_2004\_01\oasis_200401_wss_wssecurity_utility_1_0_xsd • org\oasis_open\docs\www\wss\_2004\_01\oasis_200401_wss_wssecurity_secext_1_0_xsd • Demo http://nodal.ercot.com 40

  41. Setting Up a Client (Java) - Sample Java Client • Sample java client uses below configuration files • client.properties • Contains security information used for transport level security such as keystores, truststores, passwords and type information for the keystores, truststores. It also contains location of the wsdd file. • client.wsdd • Contains properties needed by Axis when invoking web services. • crypto.properties • Contains properties for the certificate used for request signatures. http://nodal.ercot.com 41

  42. Setting Up a Client (Java) - Example • Code snippet from sample java client #Construct the EngineConfiguration object based on the wsdd (Web service deployment definition) file. EngineConfiguration config = new FileProvider("WSDDFILE"); #It is this object that provides the configuration for the Web service locator. #Construct the Web service implementation object. NodalServiceLocator locator = new NodalServiceLocator(config); #Set the endpoint address (default endpointURL will be the one specified in wsdl file used in wsdl2java). #default endpoint url will be the one specified in wsdl file. locator.setHttpEndPointEndpointAddress("END_POINT_URL"); #Get the Binding Stub from the webservice implementation object Operations stub = locator.getHttpEndPoint(); #Construct the request object that will be used during the execution of the service. RequestMessage request = new RequestMessage(); request = parseRequestXML("INPUT FILE"); #Invoke the service method on the binding stub #Response object will be returned upon invoking the service method on the binding stub that was created from the locator. ResponseMessage response; response = stub.marketTransactions(request); http://nodal.ercot.com 42

  43. Setting Up a Client (Java) - Client Demo w/o Security • Java Client Demo (without security configuration) • Sample Request Message <COP> • XSD  Request XML • Execute Java Client • Error Message • ERCOT Requires Authentication and Authorization • Client’s (even in sandbox) must use SSL and a valid digital certificate http://nodal.ercot.com 43

  44. Setting Up a Client (Java) – Implementing Security • Security • Keystore & Truststore • Storage file containing keys, certificates, trusted roots. • KeyTool GUI is used to generate keystores and truststores. • KeyTool GUI Demo • transport keystore entries • Client Certificate • truststore entries • Verisign Root & Intermediate Certificates • message keystore entries • Client Certificate • ERCOT Public Key • Sample java client uses below configuration files • client.properties • Contains security information used for transport level security such as keystores, truststores, passwords and type information for the keystores, truststores. It also contains location of the wsdd file. • client.wsdd • Contains properties needed by Axis when invoking web services. • crypto.properties • Contains properties for the certificate used for request signatures. http://nodal.ercot.com 44

  45. Setting Up a Client (Java) - Implementing Security • (Review) Sample java client uses below configuration files • client.properties • Contains security information used for transport level security such as keystores, truststores, passwords and type information for the keystores, truststores. It also contains location of the wsdd file. • client.wsdd • Contains properties needed by Axis when invoking web services. • crypto.properties • Contains properties for the certificate used for request signatures. http://nodal.ercot.com 45

  46. Setting Up a Client (Java) - Implementing Security (client.properties) • client.properties #The location of the client keystore used for the transport level security javax.net.ssl.keyStore=transport_keystore.jks #The type of keystore being used. javax.net.ssl.keyStoreType=jks #The keystore's password javax.net.ssl.keyStorePassword=changeit #Location of the truststore file javax.net.ssl.trustStore=client_truststore.jks #truststore’s password javax.net.ssl.trustStorePassword=changeit #The type of truststore being used javax.net.ssl.trustStoreType=jks #This is the location of the Web service deployment definition file. webservice.deployment.definition.file=client.wsdd http://nodal.ercot.com 46

  47. Setting Up a Client (Java) - Implementing Security (client.wsdd) • client.wsdd <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/> <globalConfiguration > <requestFlow > <!-- For each request sent from client... --> <handler type= "java:org.apache.ws.axis.security.WSDoAllSender" > <!-- Insert signature in requests --> <parameter name="action" value="Signature"/> <!-- Alias name of the certificate from the keystore --> <parameter name="user" value=“<CERT_ALIAS_NAME>" /> <!-- This is the callback class that implements a method to get certs password. --> <parameter name="passwordCallbackClass" value=“<PasswordCallBackClassName>"/> <!– keystore is defined in crypto.properties file. --> <parameter name="signaturePropFile" value="crypto.properties" /> <!– Specifies the format used by handler to insert signature into request. DirectReference causes the handler to convert the signing certificate to BinarySecurityToken element that is pit in security header --> <parameter name="signatureKeyIdentifier" value="DirectReference" /> </handler> </requestFlow> <responseFlow> <handler type= "java:org.apache.ws.axis.security.WSDoAllReceiver" > <parameter name="action" value="Signature"/> <parameter name="passwordCallbackClass" value="PWCallback"/> <parameter name="signaturePropFile" value="crypto.properties" /> <parameter name="enableSignatureConfirmation" value="false"/> </handler> </responseFlow> </globalConfiguration > </deployment> http://nodal.ercot.com 47

  48. Setting Up a Client (Java) - Implementing Security (crypto.properties) • crypto.properties org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin #Type of the keystore org.apache.ws.security.crypto.merlin.keystore.type=<KEYSTORE_TYPE> #Client keystores password org.apache.ws.security.crypto.merlin.keystore.password=<KEYSTORE_PASSWORD> #Alias name of the client cert in the keystore org.apache.ws.security.crypto.merlin.keystore.alias=<CERT_ALIAS_NAME> #Password of the client cert in the keystore org.apache.ws.security.crypto.merlin.alias.password=<CERT_ALIAS_PASSWORD> #The location of the client keystore used for the signing the message org.apache.ws.security.crypto.merlin.file=<KEYSTORE_LOCATION> http://nodal.ercot.com 48

  49. Setting Up a Client (Java) - Implementing Security (client demo) • Java Client Demo • Sample Request Message • Execute Java Client (with security) • Sample Response Message http://nodal.ercot.com 49

  50. Setting Up a Client(.NET) http://nodal.ercot.com 50

More Related