t-soa-uc-pr-01.doc

875 views

Published on

  • Be the first to comment

  • Be the first to like this

t-soa-uc-pr-01.doc

  1. 1. 1 2Telecom SOA Use Cases and Issues 3Version 1.0 4Committee Draft 01 / Public Review 01 519 October 2009 6 7Specification URIs: 8This Version: 9 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/cd01-pr01/t-soa-uc-pr-01.html 10 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/cd01-pr01/t-soa-uc-pr-01.pdf (Authoritative) 11 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/cd01-pr01/t-soa-uc-pr-01.doc 12 13Previous Version: 14 N/A 15 16Latest Version: 17 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/t-soa-uc.html 18 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/t-soa-uc.pdf (Authoritative) 19 http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/ t-soa-uc.doc 20 21Technical Committee: 22OASIS SOA for Telecom (SOA-Tel) TC 23 24Chair(s): 25 Mike Giordano, giordano@avaya.com 26Editor(s): 27 Enrico Ronco, enrico.ronco@telecomitalia.it 28Related work: 29 This specification replaces or supersedes: 30 • Not Applicable 31 This specification is related to: 32 • Not Applicable 33 34Declared XML Namespace(s): 35 Not Applicable 36Abstract: 37 This document is the first deliverable produced within the OASIS SOA for Telecom (SOA-TEL) 38 TC and has the objective of collecting potential technical issues and gaps of SOA standards 39 (specified by OASIS and other SDOs) utilized within the context of Telecoms. 1t-soa-uc-pr-01 19 October 2009 2Copyright © OASIS® 2009. All Rights Reserved. Page 1 of 54
  2. 2. 40 All perceived technical issues on SOA standards contained in this document are structured with a 41 description of the context, a use case, and a rationalization of the possible gap within the 42 standard. 43 Amongst future deliverables of the SOA-TEL TC there is a Requirements specification, which will 44 aim to extend the current core SOA enabling stack (Web Services and/or REST, etc.) in support 45 of Telecom needs on the basis of the issues identified within the present document. 46Status: 47 This document was last revised or approved by the OASIS SOA for Telecom (SOA-Tel) TC on 48 the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest 49 Approved Version” location noted above for possible later revisions of this document. 50 Technical Committee members should send comments on this specification to the Technical 51 Committee’s email list. Others should send comments to the Technical Committee by using the 52 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/ 53 committees/soa-tel/. 54 For information on whether any patents have been disclosed that may be essential to 55 implementing this specification, and any offers of patent licensing terms, please refer to the 56 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 57 open.org/committees/soa-tel/ipr.php). 58 The non-normative errata page for this specification is located at http://www.oasis- 59 open.org/committees/soa-tel/. 4t-soa-uc-pr-01 19 October 2009 5Copyright © OASIS® 2009. All Rights Reserved. Page 2 of 54
  3. 3. 60Notices 61Copyright © OASIS® 2009. All Rights Reserved. 62All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 63Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 64This document and translations of it may be copied and furnished to others, and derivative works that 65comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 66and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 67and this section are included on all such copies and derivative works. However, this document itself may 68not be modified in any way, including by removing the copyright notice or references to OASIS, except as 69needed for the purpose of developing any document or deliverable produced by an OASIS Technical 70Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 71be followed) or as required to translate it into languages other than English. 72The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 73or assigns. 74This document and the information contained herein is provided on an "AS IS" basis and OASIS 75DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 76WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 77OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 78PARTICULAR PURPOSE. 79OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 80necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 81to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 82such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 83produced this specification. 84OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 85any patent claims that would necessarily be infringed by implementations of this specification by a patent 86holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 87Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 88claims on its website, but disclaims any obligation to do so. 89OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 90might be claimed to pertain to the implementation or use of the technology described in this document or 91the extent to which any license under such rights might or might not be available; neither does it represent 92that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 93rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 94OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 95to be made available, or the result of an attempt made to obtain a general license or permission for the 96use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 97Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 98information or list of intellectual property rights will at any time be complete, or that any claims in such list 99are, in fact, Essential Claims. 100The names "OASIS", “SOA-TEL”, are trademarks of OASIS, the owner and developer of this 101specification, and should be used only to refer to the organization and its official outputs. OASIS 102welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce 103its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above 104guidance. 105 7t-soa-uc-pr-01 19 October 2009 8Copyright © OASIS® 2009. All Rights Reserved. Page 3 of 54
  4. 4. 106Table of Contents 1071 Introduction..............................................................................................................................................7 108 1.1 Terminology......................................................................................................................................7 109 1.2 Normative References......................................................................................................................8 110 1.3 Non-Normative References..............................................................................................................8 1112 Context setting.........................................................................................................................................9 1123 Issues on Addressing and Notification...................................................................................................12 113 3.1 Transaction Endpoints Specification...............................................................................................12 114 3.1.1 Scenario/context......................................................................................................................12 115 3.1.2 Use Case.................................................................................................................................12 116 3.1.3 Perceived Technical Issue.......................................................................................................14 117 3.2 WS-Notification...............................................................................................................................14 118 3.2.1 Scenario/context......................................................................................................................14 119 3.2.2 Use Case (A)...........................................................................................................................14 120 3.2.3 Perceived technical issue (A)..................................................................................................15 121 3.2.4 Use Case (B)...........................................................................................................................16 122 3.2.5 Perceived Technical issue (B).................................................................................................17 1234 Issues on communications protocols.....................................................................................................18 124 4.1 SOAP .............................................................................................................................................18 125 4.1.1 Scenario/context .....................................................................................................................18 126 4.1.2 Use Case ................................................................................................................................18 127 4.1.3 Perceived Technical issue.......................................................................................................22 1285 Issues on Security..................................................................................................................................25 129 5.1 SAML Token Correlation................................................................................................................25 130 5.1.1 Scenario/context......................................................................................................................25 131 5.1.2 Use Case.................................................................................................................................25 132 5.1.3 Perceived Technical issue.......................................................................................................27 133 5.2 SAML Name Identifier Request......................................................................................................28 134 5.2.1 Scenario/context......................................................................................................................28 135 5.2.2 Use Case.................................................................................................................................28 136 5.2.3 Perceived Technical issue.......................................................................................................29 137 5.3 SAML Attribute Management Request...........................................................................................29 138 5.3.1 Scenario/context......................................................................................................................29 139 5.3.2 Use Case.................................................................................................................................30 140 5.3.3 Perceived Technical issue.......................................................................................................31 141 5.4 User ID Forwarding ........................................................................................................................32 142 5.4.1 Scenario/context......................................................................................................................32 143 5.4.2 Use Cases...............................................................................................................................32 144 5.4.3 Perceived Technical issue.......................................................................................................35 1456 Issues on Management..........................................................................................................................37 146 6.1 Introduction.....................................................................................................................................37 147 6.2 Scenario/context ............................................................................................................................37 148 6.3 Services exposing Management Interface......................................................................................37 10t-soa-uc-pr-01 19 October 2009 11Copyright © OASIS® 2009. All Rights Reserved. Page 4 of 54
  5. 5. 149 6.3.1 Perceived Technical Issues.....................................................................................................39 150 6.4 Metadata in support of Service Lifecycle Management..................................................................39 151 6.4.1 Perceived Technical issues.....................................................................................................42 152 6.5 Recap of issues and considerations for OASIS SOA-Tel analysis.................................................42 1537 Issues on SOA collective standards usage............................................................................................44 154 7.1 Common Patterns for Interoperable Service Based Communications............................................44 155 7.1.1 Scenario/purpose....................................................................................................................44 156 7.1.2 Scenario/context .....................................................................................................................46 157 7.1.3 Technical Issues/ Solutions: ...................................................................................................49 1588 Conformance.........................................................................................................................................50 159 Appendix A. Acknowledgements..............................................................................................................51 160 Appendix B. Web Services Standards Landscape...................................................................................52 161 Appendix C. Possible workaround related to issue in Section 3.1 “Transaction Endpoints Specification” 162...................................................................................................................................................................53 163 164 13t-soa-uc-pr-01 19 October 2009 14Copyright © OASIS® 2009. All Rights Reserved. Page 5 of 54
  6. 6. 165Table of Figures 166 167Figure 1: Reference Schema to classify SOA subject areas.......................................................................9 168Figure 2: Mapping of received contributions on Reference Schema..........................................................11 169Figure 3: Transaction endpoints scenario.................................................................................................13 170Figure 4: Transaction endpoints scenario flow..........................................................................................13 171Figure 5: Notification Use Case (a) flow....................................................................................................15 172Figure 6: Notification use case (b) flow.....................................................................................................17 173Figure 7: “SOAP” use case representation...............................................................................................19 174Figure 8: SOAP message, request formulated by the Service Consumer................................................20 175Figure 9: Message needed by the Service Provider (Ultimate SOAP receiver)........................................21 176Figure 10: Message effectively forwarded by the ESB to the appropriate Service Provider......................22 177Figure 11: Simplified transaction diagram for the “SAML token correlation” use case..............................26 178Figure 12: ”SAML token correlation” use case: pictorial representation....................................................26 179Figure 13: ”SAML name Identifier request” use case: pictorial representation..........................................28 180Figure 14: “SAML Attribute Management request” use case: pictorial representation..............................30 181Figure 15: User ID Forwarding use case..................................................................................................32 182Figure 16: User ID Forwarding – “Customer care” use case.....................................................................33 183Figure 17: User ID Forwarding – “MVNO” use case.................................................................................35 184Figure 18: TM Forum “SDF Service”.........................................................................................................38 185Figure 19: Including management capabilities definition in the SDF Service description..........................38 186Figure 20: SDF Reference Model..............................................................................................................40 187Figure 21: SDF Service lifecycle phases and associated metadata..........................................................41 188Figure 22: SDF Service Metadata (concepts)...........................................................................................41 189Figure 23: Service Lifecycle Management through SDF...........................................................................42 190Figure 24: Real-time communications in the context of an “any” application seamlessly across any device 191and network ..............................................................................................................................................45 192Figure 25: Sequence diagram example for the Universal Communication Profile case ...........................47 16t-soa-uc-pr-01 19 October 2009 17Copyright © OASIS® 2009. All Rights Reserved. Page 6 of 54
  7. 7. 1931 Introduction 194Service-Oriented Architecture, SOA, is a design approach that divides everyday business applications 195into individual processes and functions, otherwise termed “service components”. These service 196components can then be deployed and integrated among any supporting applications and run on any 197computing platform. SOA enables a business to drive its application architecture by aligning the business 198processes with the information technology infrastructure. In effect the composite application becomes a 199collection of services communicating over a message bus via standard interfaces and allowing each 200component to be incorporated into the business process flow creating loosely coupled reusable 201component architecture. 202The use of SOA architectural concepts allows the developer to create complex and dynamically changing 203applications reaching out to other component providers, who may be inside the organization or an 204external third party component provider. 205From the perspective of an application developer, SOA is a set of programming models and tools for 206creating, locating, and building services that implement business processes. SOA presents a 207programming model to build complex composite services, and at this time the current industry approach 208uses web service technologies to implement SOA. 209The next generation of applications are adopting a composite model where the components that are 210involved in the application execution path may be obtained from the efforts of multiple providers, each 211specializing in certain core competencies. These components will need to provide an open standards 212based interface to the application plane that is consumable by the tooling that the business community is 213comfortable with using. This makes it easier to combine components into applications to meet the needs 214of customers, suppliers and business partners. 215This approach allows the application service provider to offer complex services, whose behavior can be 216dynamically managed to offer the optimal experience for the end user. As well as providing a mechanism 217to develop rapid applications there are also various management and deployment areas that need to be 218handled in this multi-component multi-vendor model as each component may have specific deployment or 219management considerations. 220The use of SOA technology within the telecommunications area is expanding as by using a standardized 221interface to the network the telecommunications enablers can be exposed for consumption by the IT 222applications running in the business plane. These interfaces can be based upon various aspects of SOA, 223WSDL, Web Services Description Language, a REST, REpresentational State Transfer, model or other 224technology. In any case the consuming application can use the relevant IT tool set to bring these enablers 225into the business process to supply a real time communications service component. 226Part of the work being undertaken by the OASIS SOA-TEL TC is to understand how SOA-related 227specifications and standards are used within the scope of the telecommunications environment and 228determine if there are any issues when used in this manner. 229The objective of this deliverable is to identify possible technical issues related to the utilization of current 230SOA standards and specifications in the context of telecommunications. Such issues or gaps are 231illustrated by means of specific use cases. 232Amongst future deliverables of the SOA-TEL TC there is a Requirements specification, which will aim to 233extend the current core SOA enabling stack (Web Services and/or REST, etc.) in support of Telecom 234needs on the basis of the issues identified within the present document. 2351.1 Terminology 236The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 237NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 238in [RFC2119]. 19t-soa-uc-pr-01 19 October 2009 20Copyright © OASIS® 2009. All Rights Reserved. Page 7 of 54
  8. 8. 2391.2 Normative References 240 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 241 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 242 [WS-I Basic Profile] WS-I Basic Profile Version 1.0: "Final Material", available at 243 http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html. 244 245 [WSDL 1.1] W3C Note (15 March 2001): "Web Services Description Language (WSDL) 246 1.1". http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 247 248 [SOAP 1.2] W3C SOAP v.1.2, available at http://www.w3.org/TR/soap12-part1/ 249 250 [WS-N 1.3] OASIS Standard, “Web Services Base Notification 1.3 (WS- 251 BaseNotification)”, version 1.3, 1 October 2006. http://docs.oasis- 252 open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm 253 254 [WS-A 1.0] W3C Web Services Addressing 1.0 – Core W3C Recommendation 9 May 255 2006, http://www.w3.org/TR/2006/REC-ws-addr-core-20060509 256 257 [WS-S 1.1] OASIS Standard, “Web Services Security specification, version1.1”, 1 258 February 2006. http://docs.oasis-open.org/wss/oasis-wss-saml-token- 259 profile-1.0.pdf and http://docs.oasis-open.org/wss/oasis-wss-rel-token- 260 profile-1.0.pdf 261 262 [SOA RM 1.0] OASIS Standard, “OASIS Reference Model for Service Oriented Architecture 263 1.0”, Oct. 12, 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf 264 265 [SCA Assembly 1.1] OASIS Committee Draft 03, “Service Component Architecture Assembly 266 Model Specification Version 1.1”, Mar. 09, http://docs.oasis- 267 open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.html 268 269 [SOA RA 1.0] OASIS Public Review Draft 01, “ Reference Architecture for Service Oriented 270 Architecture 1.0”, Apr. 2008, http://docs.oasis-open.org/soa-rm/soa- 271 ra/v1.0/soa-ra-pr-01.pdf 272 273 [WSDL 2.0] W3C Web Services Description Language (WSDL) Version 2.0 Part 0: 274 Primer, http://www.w3.org/TR/2007/REC-wsdl20- 275 primer-20070626/Recommendation, June 2007 276 277 [SAML 2.0] OASIS Standard, “Assertions and Protocol for the OASIS Security Assertion 278 Markup Language (SAML) V2.0”, March. 2005, http://docs.oasis- 279 open.org/security/saml/v2.0/saml-2.0-os.zip 280 2811.3 Non-Normative References 282 283 [WS Landscape] Possible representation of web services specification landscape, available at 284 http://www.innoq.com. 22t-soa-uc-pr-01 19 October 2009 23Copyright © OASIS® 2009. All Rights Reserved. Page 8 of 54
  9. 9. 2852 Context setting 286This section provides a rationale for the classification of the issues presented in the document. 287Literature on SOA is vast, as the theme has acquired increasing importance and relevance over time. 288Contextualizations and generalizations can be a difficult task, since many perspectives could be taken 289into account and importance perceptions may vary depending on reader’s interests. 290Nevertheless, Figure 1 is an attempt to provide a context rationalization of items related to SOA: it was 291built not with the intent of being rigorous, but rather to provide a possible classification schema for the 292readers of this document. 293 294 295 296 Figure 1: Reference Schema to classify SOA subject areas 297 298The contributions received and analyzed within SOA-TEL on possible issues of SOA standards in the 299Telecoms context are related to some of the subject areas depicted in Figure 2. 25t-soa-uc-pr-01 19 October 2009 26Copyright © OASIS® 2009. All Rights Reserved. Page 9 of 54
  10. 10. 300The list of received contributions is presented hereafter, while in Figure 2 a mapping of the contributions 301to the Reference Schema is provided. 3021. Transaction Endpoints Specification, related to a possible issue on the W3C WS-Addressing 303 specification; the necessity to specify the endpoint of a final result of a “process/transaction" (i.e. 304 asynchronous response) result should be sent. 3052. Notification, related to a possible issue on the OASIS WS-Notification specification; the necessity to 306 specify for the Provider of a notifications service to specify the endpoint to which the Notification 307 should be sent. 3083. SOAP Protocol issue, related on a possible issue on the W3C SOAP specification; the necessity for 309 an “intermediate SOAP node” to also cover the role of “SOAP ultimate receiver node”. 3104. SAML Token Correlation, related to a possible issue on the OASIS WS-Security specification; the 311 necessity of enabling “correlation” of a security token to another. 3125. SAML Name Identifier Request, related to a possible issue on the OASIS SAML specification: the 313 possibility to extend the SAML protocol to enable a Service provider (SP) to register single Users with 314 an Identity Provider (IdP) “on-the-fly”, as the need arises. 3156. SAML Attribute Management, related to a possible issue on the OASIS SAML specification: the 316 possibility to extend the SAML protocol to enable a SP (Service Provider) to transmit user attributes 317 to be stored within an IdP (Identity Providers). 3187. User-ID Forwarding, related to a possible issue in the OASIS WS-Security specification; the 319 necessity to define a common means to add two (or more) credentials in one message. 3208. Services exposing Management Interface, related to possible issues on the OASIS SOA 321 Reference Model (SOA RM) and SOA Service Component Architecture (SCA) Assembly Model; the 322 necessity to specify more than one service interface for a single SOA service. 3239. Metadata in support of Service Lifecycle Management, related to the possibility to enrich the 324 OASIS SOA Reference Architecture (SOA RA) with metadata necessary for Service Lifecycle 325 Management identified within the TM Forum SDF program. 32610. Universal Communications Profile, related to the specification of a possible common profile for 327 universal interoperability across domains. 28t-soa-uc-pr-01 19 October 2009 29Copyright © OASIS® 2009. All Rights Reserved. Page 10 of 54
  11. 11. 328 1. T ran s ac tion D e sk to p P ro fil e D eskt o p P r o file En d points S y s tem S yst e m H yb rid W eb P ro fil e (I.e.. B 2 B ,, clo u d ,, F AT W eb P ro file (I.e B 2B clo ud R IA Sp e cific atio n M ob iil e P ro file so c ial..) so c ia l..) M ob le P ro file 2. N o tific atio n Inter-o perab ility 3. SO A P P ro toc o l 7 8 4. SA M L To ke n C o m m u n ic ati o ns C o m m un ic atio n s P ro file 1 0 P ro file 1 3 C o rrelatio n S e rv ice Fra m ew o rk S e rv ice F ram ew o rk 5. SA M L N am e 4 5 2 Event N otification Telec om M anagem e nt SOA Profile Ide n tifie r R e q u es t 6 Pre sentation and Enc oding Service Facades 6. SA M L A ttrib u ite M a na gem e nt em e nt Id entity M an ag e m en t C o m po ne n tt C o m p o nen L ife C ycle M g m tt 9 E ven tt D riven L ife C ycle M g m Ev en D riven 7. U s e r-ID S ervic e S e rv ic e A rchitec ture A rc hitec tu re S ec u rity S ecu rity T ier T ier P olicy F o rw a rd in g P 8. Se rvic es e x po s in g Id en tity M a na gem e nt A b strac tio n Abs tr ac tio n Interfac e SIP ,, C ST A… o th er SIP C ST A… o ther 9. M e ta da ta in s up p o rt of Se rvice L ifec yc le M a na gem e nt 10 . U nive rsa l C o m m u n ic ation s 329 Pro file 330 331 Figure 2: Mapping of received contributions on Reference Schema 332 333The document is organized in the following sections: 334• Section 3, Issues on Addressing and Notification; 335• Section 4, Issues on Communication Protocols; 336• Section 5, Issues on Security; 337• Section 6, Issues on Management; 338• Section 7, Issues on SOA collective standards usage. 339 340All perceived technical issues on SOA standards contained in this document are structured with a 341description of the context, a use case, and a rationalization of the possible gap within the standard. 31t-soa-uc-pr-01 19 October 2009 32Copyright © OASIS® 2009. All Rights Reserved. Page 11 of 54
  12. 12. 3423 Issues on Addressing and Notification 3433.1 Transaction Endpoints Specification 3443.1.1 Scenario/context 345The issue presented in this section derives from a concrete case, implemented within an operator’s SOA 346Middleware. 347The operator is in the process of deploying a SOA infrastructure, of which some of the constituting 348elements are an ESB (Enterprise Service Bus), a BPM (Business Process Manager), some “Service 349Consumers (systems or applications), some “Service Providers” (systems or applications). 350An aspect to be considered is that to satisfy performance criteria it has been decided that the ESB must 351be intrinsically “stateless” (i.e. it must not store any persistence information on destination of incoming 352service requests). 353Moreover, the “number” of ESB can vary, i.e. there can be interconnected trunks of different vendors’ 354ESB. 3553.1.2 Use Case 356The following Use Case describes the technical problem (Figure 3 and Figure 4). To improve readability 357the depicted use case presents only one instance of ESB, but the possible solution to the problem must 358satisfy also the cases of multiple instances of ESB. 359A Service Consumer (C1 or C2) invokes a Service, implemented as a Web Service (Web Service A). 360Such WSA is achieved as an “itinerary” with the composition of more elementary services, provided by 361Provider P1 and Provider P2. 362The ESB provides intermediary services for final exposition, enrichment and Data reconciliation and 363routing. 364 • Case A: C1 is the originator and final receiver. 365 • Case B: C2 is the originator and final receiver. 366 34t-soa-uc-pr-01 19 October 2009 35Copyright © OASIS® 2009. All Rights Reserved. Page 12 of 54
  13. 13. 367 c2 c1 6a 1b 1a 6b 5 WS A WS C resp ESB WS B WS C WS B resp 2 4 3 Provider P1 Provider P2 368 Figure 3: Transaction endpoints scenario 369 370 371 372 Figure 4: Transaction endpoints scenario flow 37t-soa-uc-pr-01 19 October 2009 38Copyright © OASIS® 2009. All Rights Reserved. Page 13 of 54
  14. 14. 373Use Case Steps: 374Case A 375 • C1 invokes WSA, exposed by ESB. 376 • WSA is executed with the internal composition (transparent to C1) and with intermediary services 377 provided by the ESB. 378 • At the end of the internal interactions, the ESB forwards the response to C1. 379Case B 380 • C2 invokes WSA, exposed by ESB. 381 • WSA is executed with the internal composition (transparent to C2) and with intermediary services 382 provided by the ESB. 383 • At the end of the internal interactions, the ESB forwards the response to C2. 3843.1.3 Perceived Technical Issue 385With the current knowledge and expertise, in presence of an ESB offering intermediary services, there is 386no formal way to specify the endpoint (e.g. C1 or C2) to which the final result of a “process/transaction" 387(i.e. asynchronous response) result should be sent. 388Affected specification is W3C [WS-A]. 3893.2 WS-Notification 3903.2.1 Scenario/context 391Event-Driven Architectures are extremely important in environments, like Telecoms, where it is necessary 392to handle massive network events that have a business value to registered subscribers. 393Often these solutions rely on proprietary protocols that work against the implementation of SOA 394principles. 395There’s a strong technical and business need for a Notify/Subscribe protocol which could be widely 396adopted and used by Vendors and Telecom Operators. Moreover the protocol should support the 397presence of intermediaries between the Subscriber and the Notifier. 398In the following, 2 use cases and related issues are presented, one related to a lack of acceptance of an 399existing standard by the vendor community, and one on a specific technical issue on existing standards. 400 401Specifications addressed within this section are: 402• OASIS Web Services Base Notification 1.3 (WS-BaseNotification) [WS-N], OASIS Standard, 1 403 October 2006, http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm 404• W3C Web Services Addressing 1.0 [WS-A] – Core W3C Recommendation 9 May 2006, 405 http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. 4063.2.2 Use Case (A) 407The following Use Case describes a technical problem which is common for a Telecom Operator (ref. 408Figure 5). 409An Application wants to be notified when a specific “Large Account Mobile Number” receives an SMS with 410a specific keyword in the message content. 411Use Case Steps: 412 1. The Application informs the Provider that it wants to be notified when the specified Large Account 413 Number “33536821686” receives an SMS containing the word “poll”. 414 40t-soa-uc-pr-01 19 October 2009 41Copyright © OASIS® 2009. All Rights Reserved. Page 14 of 54
  15. 15. 415 2. The Provider notifies the Application when an incoming event from the underlying network 416 responds to the Subscribing criteria. 417 3. The Application informs the Provider that it does not want to be notified anymore when the 418 specified Large Account Number “33536821686” receives an SMS containing the word “poll”. 419 420 421 422 423 Figure 5: Notification Use Case (a) flow 424 4253.2.3 Perceived technical issue (A) 426Currently a commonly used interoperable standard does not exist to address “Notify/Subscribe message 427exchanges”. 428The last approved specification, OASIS WS-Notification [WS-N], has been very poorly adopted by the 429vendors community and consequently has no interoperability value. 430The need is that such specification gets endorsed/adopted by the vendor community in order for it to add 431value in this specific context. 432 433Such lack is perceived as a strong market gap with negative impacts for both Telecom Operators and 434Third Parties involved in the development of new services: 4351) Operators are limited in their business development since they must rely on costly proprietary 436 solutions and customizations implemented by vendors; 4372) Third Parties, who are typically involved in developing new services for their customers, can not fully 438 exploit in their services development the open network infrastructures provided by Telco Operators. 439 43t-soa-uc-pr-01 19 October 2009 44Copyright © OASIS® 2009. All Rights Reserved. Page 15 of 54
  16. 16. 4403.2.4 Use Case (B) 441The following Use Case describes a second technical problem which is common for Telecom Operators 442(ref. Figure 6). 443An Application must be notified when a specific “Large Account Mobile Number” receives an SMS with a 444specific keyword in the message content. There are one or more intermediaries between the Application 445and the Provider. 446 447Use Case Steps: 448 1. The Application informs the Intermediary that it wants to be notified when the specified Large 449 Account Number “33536821686” receives an SMS containing the word “poll”. 450 451 2. The Intermediary sends the subscription request to the Provider. 452 453 3. The Provider notifies the Intermediary when an incoming event from the underlying network 454 responds to the Subscribing criteria. 455 456 4. The Intermediary sends the notification to the Application. 457 458 5. The Application informs the Intermediary that it does not want to be notified anymore when the 459 specified Large Account Number “33536821686” receives an SMS containing the word “poll”. 460 461 6. The Intermediary sends the “unsubscribe” request to the Provider. 462 463 464 465 46t-soa-uc-pr-01 19 October 2009 47Copyright © OASIS® 2009. All Rights Reserved. Page 16 of 54
  17. 17. 466 Figure 6: Notification use case (b) flow 4673.2.5 Perceived Technical issue (B) 468The last approved specification to support Notify/Subscribe patterns, WS-Notification [WS-N], relies on 469W3C WS-Addressing [WS-A] for the asynchronous delivery of notifications, which means that there is no 470formal way for the Provider to specify the endpoint to which the Notification should be sent. 471As an example, in the case illustrated above there is no standard way for the Provider to indicate the 472original Application as destination of the notification, due to the presence of intermediary (ies) in the path. 473 474The issue on WS-A impacts thus also the WS-N specification. Refer to Section 3.1 within this document 475for the technical issues with the WS-A specification. 476 “in presence of intermediary, there is no formal way to specify the endpoint to which the final 477 result of a “process/transaction" (i.e. asynch. response) result should be sent.” 478 479The technical problem here exposed prevents Telecom Operators to develop standardized solutions for 480the management of “multiple notify/subscribe patterns”, and forces to rely on costly customizations and 481proprietary solutions. 482 49t-soa-uc-pr-01 19 October 2009 50Copyright © OASIS® 2009. All Rights Reserved. Page 17 of 54
  18. 18. 4834 Issues on communications protocols 4844.1 SOAP 4854.1.1 Scenario/context 486The issue presented in this section derives from a concrete case, occurred within the context of the 487development of a platform for Mobile Virtual Network Operators (MVNOs). 488This section is related to a possible technical issue within the SOAP 1.2 [SOAP 1.2] specification, in 489particular on the “SOAP Intermediary” and “Ultimate SOAP receiver” concepts. 490The specification defines the following (within its section 1.5.3): 491 • Initial SOAP sender – The SOAP sender that originates a SOAP message at the starting point of a SOAP message path. • SOAP intermediary – A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver. • Ultimate SOAP receiver – The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message (see 2. SOAP Processing Model). 492 493 494In particular it is stated that 495 • A SOAP Intermediary processes the header of a SOAP message. 496 • An Ultimate SOAP receiver processes the body of a SOAP message and can not also be a 497 SOAP intermediary for the same SOAP message. 498The issue presented in the following Use Case illustrates the need to have a SOAP Intermediary which 499must process the body of a SOAP message in addition to its “canonical” role of processing the SOAP 500message header. 501The case is included within the activities of deployment of a company-ware SOA infrastructure, of which 502some of the constituting elements are an ESB (Enterprise Service Bus), some “Service Consumers 503(systems or applications), some “Service Providers” (systems or applications), a BPM (Business Process 504Manager), etc. 5054.1.2 Use Case 506A Service Consumer C1 (e.g. a CRM application) invokes a Web Service to execute a transaction within a 507specific business process for the management of Mobile Virtual Network Operators (ref. Figure 7). 508The access point for the Consumer C1 is the ESB, which exposes such Web Service and moreover 509executes some of its typical functions such as Data Enrichment and Content Based Routing (CBR). 510 52t-soa-uc-pr-01 19 October 2009 53Copyright © OASIS® 2009. All Rights Reserved. Page 18 of 54
  19. 19. C1 CRM Application 1 ESB 2a 2b Service Service 511 Provider 1 Provider 2 512 513 Figure 7: “SOAP” use case representation 514 515Figure 8 contains the SOAP message which is the request formulated by the Service Consumer (e.g. the 516CRM application) to the ESB. 517The request contains: 518 • A SOAP Envelope (in black color). This is enclosed for completeness but is not subject of 519 discussion within this contribution; 520 • the SOAP Header, in red color; 521 • The SOAP message Body, in blue (and green) color. 522 523With reference to the SOAP 1.2 specification, the ESB is a “SOAP Node” (ref. Section 1.5 in the [SOAP 5241.2] specification). 525 55t-soa-uc-pr-01 19 October 2009 56Copyright © OASIS® 2009. All Rights Reserved. Page 19 of 54
  20. 20. 526 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://operator/BSS/MVNO/NetProvisioningCustomTypes"> <SOAP-ENV:Header> <m:Header xmlns:m="http://operator/BSS/MVNO/NetProvisioningHeaderTypes"> <m:sourceSystem>String</m:sourceSystem> <m:businessID>String</m:businessID> </m:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> <m:Context> <m0:value>String</m0:value> </m:Context> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 527 528 Figure 8: SOAP message, request formulated by the Service Consumer 529 530The ESB for this use case must process the body of the SOAP message in order to perform 2 operations: 531 1. “Data Enrichment”, 532 The ESB queries a provisioning system to obtain the IMSI of the asset (mobile phone number) 533 in order to add such data to the message: it invokes a Web Service, exposed by that system, 534 which takes in input the ICCD, present in the message, and returns the IMSI. 535 2. CBR (Content Based Routing) 536 The ESB decides on the final receiver of the SOAP message on the basis of the content of the 537 “Context” field (in green in Figure 2). 538 Once such tasks are performed, the ESB deletes the “Context” field from the message and 539 subsequently forwards the SOAP message to the selected Service Provider. 540 58t-soa-uc-pr-01 19 October 2009 59Copyright © OASIS® 2009. All Rights Reserved. Page 20 of 54
  21. 21. 541 Note: 542 The Data Enrichment task is executed with the collaboration of other “Service Providers” (different 543 than SP1 or SP2), but it is not a subject to be discussed within this contribution: for this reason details 544 are omitted. 545 546After such tasks are complete, the ESB must forward the SOAP message to the selected Service 547Provider, which is the “real” Ultimate SOAP receiver. The message that must be finally sent to the SP by 548the ESB is the one depicted in Figure 9. 549It is fundamental to state that the Service Provider needs the header present in the SOAP message, e.g. 550because the content of the “business ID” field can not be associated to the body of the SOAP message. 551 552 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- Figure 9: 553 ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- Message 554 instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" needed 555 xmlns:m0="http://operator/BSS/MVNO/NetProvisioningCustomTypes"> by the 556 <SOAP-ENV:Header> Service 557 <m:Header xmlns:m="http://operator/BSS/MVNO/NetProvisioningHeaderTypes"> Provider 558 (Ultimate <m:sourceSystem>String</m:sourceSystem> 559 SOAP 560 <m:businessID>String</m:businessID> receiver) </m:Header> 561 </SOAP-ENV:Header> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://operator/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> <m0:IMSI>String</m0:IMSI> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 562Nevertheless, given the initial definitions (section 1.5.3 of the SOAP Specification), since the ESB needs 563to elaborate the body of the message, it becomes an “Ultimate SOAP receiver” and thus can not be 564simultaneously classified as “SOAP Intermediary”. 565The consequence of this is that the ESB can not forward the header of the SOAP message to the 566selected Service Provider (i.e. to the “real” Ultimate SOAP receiver). 61t-soa-uc-pr-01 19 October 2009 62Copyright © OASIS® 2009. All Rights Reserved. Page 21 of 54
  22. 22. 567Thus the message really forwarded by the ESB is depicted in Figure 10. 568 569 570 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- 571 ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- Figure 572 instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 10: xmlns:m0="http://operator/BSS/MVNO/NetProvisioningCustomTypes"> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://operator/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> <m0:IMSI>String</m0:IMSI> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 573 Message effectively forwarded by the ESB to the appropriate Service Provider 574 575This is a real case faced by the operator, and to overcome the problem some costly ad-hoc 576developments-customizations were necessary to re-build / reinsert the necessary header within the 577message before the ESB could forward the “complete” message to the final Service Provider. 5784.1.3 Perceived Technical issue 579In the SOAP specification the following is stated. 580------------------- 5812.1 SOAP Nodes 582A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. A 583SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing 584model as described in this section and in the remainder of this specification, etc. 585 586 587 5882.2 SOAP Roles and SOAP Nodes 589In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is 590identified by a URI known as the SOAP role name. The roles assumed by a node MUST be invariant 591during the processing of an individual SOAP message. This specification deals only with the processing 64t-soa-uc-pr-01 19 October 2009 65Copyright © OASIS® 2009. All Rights Reserved. Page 22 of 54
  23. 23. 592of individual SOAP messages. No statement is made regarding the possibility that a given SOAP node 593might or might not act in varying roles when processing more than one SOAP message. 594 595Table 2 defines three role names which have special significance in a SOAP message (see 2.6 596Processing SOAP Messages). 597 Table 2: SOAP Roles defined by this specification Short-name Name Description Each SOAP intermediary and the Next "http://www.w3.org/2003/05/soap- ultimate SOAP receiver MUST act in envelope/role/next" this role. None "http://www.w3.org/2003/05/soap- SOAP nodes MUST NOT act in this envelope/role/none" role. ultimateReceiver "http://www.w3.org/2003/05/soap- The ultimate receiver MUST act in envelope/role/ultimateReceiver" this role. 598 599In addition to the SOAP role names defined in Table 2, other role names MAY be used as necessary to 600meet the needs of SOAP applications. 601------------------- 602 603Due to the fact that the ESB (as a SOAP Node) processes the body of the message, it is classified as 604“ultimateReceiver”. 605 606As a consequence, the ESB can not “Forward” the SOAP Header to the appropriate Service Provider (ref. 607Sections 2.7.1 of the SOAP specification) since it has value “ultimateReceiver”. The following table 608depicts the behavior of the ESB being an ultimateReceiver. 609 Role Header block Short-name Assumed Understood & Processed Forwarded Yes No, unless reinserted next Yes No No, unless relay ="true" Yes No, unless reinserted Yes user-defined No No, unless relay ="true" No n/a Yes Yes n/a ultimateReceiver Yes No n/a none No n/a Yes 610 611 612The case presented shows that a SOAP Intermediary (the ESB), which is clearly not the “ultimate 613receiver” of the SOAP message, is forced to assume the role of “ultimateReceiver” since it processes 614the body of the message. This prevents the ESB to correctly perform it s “proper” intermediary role, since 615“An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message”. 67t-soa-uc-pr-01 19 October 2009 68Copyright © OASIS® 2009. All Rights Reserved. Page 23 of 54
  24. 24. 616The perceived technical gap suggested by the operator is that the SOAP specification should be modified 617in order to enable a SOAP Intermediary node to “forward” the SOAP Header in automatic mode (thus 618without the Header reinsertion) even if such node performs some processing operation over the body of 619the SOAP message. 620Another way of expressing this perceived gap is to state that currently only 3 roles are allowed for a 621SOAP Node (i.e. initial SOAP Sender, SOAP intermediary, SOAP ultimate receiver – section 2.1 of the 622SOAP 1.2 specification), while a probable fourth role enabling the simultaneous body processing and 623header forwarding of a specific SOAP message may be needed. 624Should the specification already enable this, OASIS SOA-TEL TC suggests to modify them in order to 625avoid possible ambiguities and misinterpretations. 626 70t-soa-uc-pr-01 19 October 2009 71Copyright © OASIS® 2009. All Rights Reserved. Page 24 of 54
  25. 25. 6275 Issues on Security 6285.1 SAML Token Correlation 6295.1.1 Scenario/context 630The issue presented in this section derives from a concrete case of telecommunications services’ sales 631and post-sales: in particular the activation and provisioning of ADSL service to residential customers. 632The business process under analysis is complex and necessitates to be orchestrated by a BPM 633(Business Process Management) application. 634Such process is a “long-running” type process: in fact one of its tasks requires a human intervention 635within the central office, which can be executed within hours (or days). 636This implies that the process must be handled in a different mode from the “security management” 637perspective. 638This section addresses potential issues within the OASIS Web Services Security specification, [WS-S 6391.1]. 6405.1.2 Use Case 641A consumer, e.g. a CRM application invokes a service to execute a specific business process, the 642activation of ADSL services for a residential customer. 643The BPM application gets in charge of the orchestration/execution of such processes. 644Given the fact that the process is “long-running”, the BPM shall, at a given point, suspend the 645orchestration/execution of the process until it will receive a specific “activity closure” event from a back 646office system once the appropriate technician will have terminated his manual tasks. 647The following schema Figure 11 depicts a simplified transaction diagram, while Figure 12 provides a 648pictorial representation of the Use Case. 649 650 CRM BPM Delivery Order request In delivery X hours/days Delivery response Order response 651 73t-soa-uc-pr-01 19 October 2009 74Copyright © OASIS® 2009. All Rights Reserved. Page 25 of 54
  26. 26. 652 Figure 11: Simplified transaction diagram for the “SAML token correlation” use case 653 CRM Delivery system Application Token IAM Issuer BPM token1 Token Issuer SEP1 Token2 selling request 1 SEP2 BPM 2 selling response token1 token1 Generic system Generic system Delivery system 654 655 656 Figure 12: ”SAML token correlation” use case: pictorial representation 657Use Case steps. 658• The CRM sends an ADSL activation request. 659• The consumer (CRM) provides its credentials to a Token Issuer and requires the generation of a 660 security token, “token1”. The token is associated to the initial message and has limited duration, since 661 extending it would mean to have a weaker security policy. 662• The Security Enforcement Point, interacting with the policy decision point (IAM) (Identity Access 663 Manager), applies the authentication and authorization policies. 664• The BPM orchestrates the process interacting with the various services exposed by the involved 665 systems within the company SOA infrastructure. All interactions are executed with the “token1” as 666 security token. 667• When appropriate, the BPM invokes a service exposed by a Delivery system to obtain a physical 668 configuration within the central office. At this stage the BPM suspends the execution of the business 669 process (the duration of the task may require hours or days), awaiting for the reception of a specific 670 “activity closure” event. 671• The Delivery System activates the technical configuration task. 672• A human intervention is performed within the central office. 673• Once this task is terminated, the technician reports the “activity closure” on the Delivery system, 674 which generates the “activity closure” event for the BPM. 675• The BPM resumes the suspended process, invoking the “next step” in the ADSL activation process. 676• If the security token “token1”is expired, the BPM requests the Token Issuer to generate a new 677 security token, “token2”, since the previous is not valid any more. 76t-soa-uc-pr-01 19 October 2009 77Copyright © OASIS® 2009. All Rights Reserved. Page 26 of 54
  27. 27. 678• The remaining portion of the process is executed utilizing the new security token, “token2”. 6795.1.3 Perceived Technical issue 680In the described scenario the issue is related to which credentials (capabilities) must be utilized to 681generate the security token “token2”. 682The BPM is responsible for the orchestration/execution of the process, and is the entity which is entitled 683to request the generation of the new security token “token2”, which is of course different from “token1”. 684This is a weakening factor for the “security architecture”, since an element of the middleware 685infrastructure (the BPM) would need to request the generation of security tokens which are not 686“correlated” (or “directly coupled”) to the real entity which requires the initiation of the business process 687(i.e. the CRM application, thus the CRM sales representative) and to the business process itself. It is a 688requirement for the Telecom Operator to reduce such potential security threats. 689It should be possible for the BPM to request the Token Issuer to generate a new token “associated” to the 690“token1”, and to maintain evidence of that correlation, in order to authorize the BPM itself, once security 691checks are validated by the IAM, to invoke all pending services within the second part of the process 692because such invocations are “really” part of a “security authorized” business process. 693The WS-Sec specification [WS-S 1.1], in Section 7 - row 824, states that mechanisms for referencing 694security tokens are defined. 695In row 870 the following is stated: 696-------- 697 870 /wsse:SecurityTokenReference/@wsse:Usage 698 871 This optional attribute is used to type the usage of the 699 872 <wsse:SecurityTokenReference>. Usages are specified using URIs and multiple 700 873 usages MAY be specified using XML list semantics. No usages are defined by this 701 874 specification. 702-------- 703 704Thus, form a syntactical perspective, the specification enables the “correlation” of a security token to 705another one, but it does not prescribe how such correlation should be formalized. 706 707Moreover, within non-normative Appendix D “SecurityTokenReference Model”, specific examples of 708security token referencing are provided, with emphasis of the “signature referencing”. 709Within this appendix, Row 2413 to 2432 do provide an example of “non-signature references”, but the 710specification states that 711 712 2430 This may be an expensive task and in the 713 2431 general case impossible as there is no way to know the "schema location" for a specific 714 2432 namespace URI. 715 716In conclusion, the lack of normative guidelines on how to address this problem is perceived as a strong 717issue for a Telecom Operator because the “correlation” problem must anyhow be solved, but adopted 718solutions result to inevitably be proprietary, costly, non-standard, vendor/platform dependent 719customizations. 720 79t-soa-uc-pr-01 19 October 2009 80Copyright © OASIS® 2009. All Rights Reserved. Page 27 of 54
  28. 28. 7215.2 SAML Name Identifier Request 7225.2.1 Scenario/context 723The context of this section is that of a SP (Service Provider) being newly added to the circle of trust of an 724IdP (identity Provider). 725Currently, as soon as a SP becomes a member of the circle of trust of an IdP, the SP is forced to import 726all of the SP’s Users into the IdP’s databases. 727The objective of this contribution is to propose a modification to the current SAML V2.0 specification 728(saml-core-2.0-os.pdf) so that the SP can be enabled to register single Users with the IdP “on-the-fly”, as 729the need arises. Such goal can be achieved with the introduction of a new SAML protocol, named “SAML 730Name Identifier Request” within the SAML specification. 731SAML supports SPs to get attributes about Users from an IdP. Regarding name identifiers, the SP usually 732sends an AuthnRequest to the IdP. Then, the IdP sends an AuthnResponse containing a NameIdentifier 733(“Subject”) back to the SP. However, if a SP is newly added to the circle of trust of an IdP, the IdP will not 734know of the User identifiers of the SP, which is required in order for the IdP to authenticate the Users of a 735SP. 736The issue highlighted in this section aims at possibly extending the SAML specifications. 7375.2.2 Use Case 738A user device, a SP and an IdP are the actors of this use case of the SAML Name Identifier Request 739mechanism. The SP is new to the circle of trust of the IdP. The IdP does not know a name identifier of the 740user device. The IdP requests a name identifier from the SP, who sends the desired name identifier to the 741IdP. 742Figure 13 provides a high-level message flow illustrating this SAML Name Identifier Request use case. 743Messages 4 and 6 belong to the SAML Name Identifier Request protocol this contribution is aiming at. 744These messages are interlaced into the SAML Authentication Request and Response exchange between 745SP and IdP and are not specified in SAML V2.0 yet (therefore, marked in red): 746 User SP IdP Device 1. Service Access Request 2. Authentication Request 3. Check for Identifier 4. Name Identifier Request 5. Prompt User to login 6. Name Identifier Response 7. Authentication Response 8. Provide Requested Service 747 748 749 Figure 13: ”SAML name Identifier request” use case: pictorial representation 82t-soa-uc-pr-01 19 October 2009 83Copyright © OASIS® 2009. All Rights Reserved. Page 28 of 54
  29. 29. 750The single steps of this use case are as follows: 751 752 1) The user requests access to a service offered by a SP. The user device does not include any 753 authentication credentials. 754 2) Since access to this service requires the User to be authenticated but the request in step 1 does 755 not include any authentication credentials, the SP sends an Authentication Request to the IdP. 756 This Authentication Request may be passed to the IdP via the user device using redirection. 757 3) The IdP checks the Authentication Request received in step 2, and - as the SP is new to the IdP’s 758 circle of trust - the IdP determines that it does not have an identifier stored in its database for the 759 User for the given SP. 760 Conventionally, the IdP would respond to the Authentication Request by issuing an error 761 message or a randomly generated identifier. This, however, is problematic: In the former case, 762 the service access request in step 1 breaks down. In the latter case, the SP has to ask the user 763 for his credentials and then send (usually via a backchannel) a message to the IdP indicating that 764 from now on the IdP should use the “real identifier” instead of the random one for the given user 765 (this could be done via the NameIdentifier Management Protocol). 766 4) This step is not defined in SAML V2.0: Since the IdP has realized in step 3 that it does not have 767 an identifier for the combination of the User and the SP, the IdP generates a message called 768 Name Identifier Request and sends it to the SP. 769 5) Upon receipt of the Name Identifier Request, the SP recognises that the IdP does not have an 770 identifier for the combination of SP and User. Therefore, the SP prompts the User to log in to the 771 SP. 772 6) This step is also not defined in SAML V2.0: The SP sends a message called Name Identifier 773 Response to the IdP. This response message includes the identifier for the combination of User 774 and SP that the IdP is to use in any further communication and authentication processes. 775 7) On receipt of the Name Identifier Response, the IdP stores the identifier contained in the Name 776 Identifier Response in its database. The IdP sends an Authentication Response to the SP, which 777 uses the identifier received in step 6. 778 8) The SP grants the User access to the requested service. 7795.2.3 Perceived Technical issue 780This contribution aims at introducing a new SAML protocol called SAML Name Identifier Request protocol 781into the SAML 2.0 specifications. 7825.3 SAML Attribute Management Request 7835.3.1 Scenario/context 784More and more services and applications are becoming available on the Internet, and many of these 785services and applications require authentication. With the convergence of telco and Internet domain, the 786telco has added functionality, namely IDM functions. The telco operator will collaborate with several SPs, 787that in return depend on the telco’s profile and attribute store. This causes a scenario where not the SP 788manages the attributes, but the telco operated IDM. 789One approach that has been developed to assist users to access multiple services and applications, each 790requiring separate authentication procedures, involves the use of identity federation. 791Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and 792authorisation data between security domains. For example, SAML is used for exchanging assertion data 793between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). 794The issue highlighted in this section aims at possibly extending the SAML specifications. 85t-soa-uc-pr-01 19 October 2009 86Copyright © OASIS® 2009. All Rights Reserved. Page 29 of 54
  30. 30. 7955.3.2 Use Case 796A user wishes to use his attribute information across multiple service providers, such attribute information 797can be layout, preferred email address, etc. Today, these attributes are stored locally at each of service 798provider. Thus, user will have to enter and changes the same attributes multiple times in order to ensure 799they are consistent for each of the different service providers the user has an account with, resulting in a 800bad user experience. 801The user creates a temporary or transient account. The service provider allows the user to set specific 802settings like coloring, text size, etc. But he/she does not want to set these setting again each time the 803user logs in because the service provider will not be able to link the attributes for a user’s temporary 804account with the user’s permanent account. This is because by the very nature of a temporary or transient 805account the next time the user logs on to the service provider the user will have a different username and 806so the service provider will not be able to link the attributes for a user’s temporary account with the user’s 807permanent account. 808 809Figure 14 provides a high-level message flow outlining the proposed SAML Attribute Management 810protocol: User Service Identity Device Provider Provider 1 . Request to cha nge attrib ute 2. Ma nageA ttribute Re quest 3. Store Attribute 4. Manag eAttrib ute Response 5. Verify 6 . Co nfi rma tion 811 812 Figure 14: “SAML Attribute Management request” use case: pictorial representation 813 814 815The ManageAttribute Request and Response messages are marked in red since the SAML 2.0 does not 816support such messages yet. The ManageAttribute Request allows the Service Provider to manage 817attributes stored on the Identity Provider side. As an example, the following XML instance of a 818ManageAttribut Request asks the Identity Provider to set the value of the “mail” attribute to 819“trscavo@gmail.com”: 820 88t-soa-uc-pr-01 19 October 2009 89Copyright © OASIS® 2009. All Rights Reserved. Page 30 of 54
  31. 31. 821The following example shows what such a change in the specification would enable to do: 822<samlp:ManageAttributeRequest 823 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 824 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 825 ID="aaf23196-1773-2113-474a-fe114412ab72" 826 Version="2.0" 827 IssueInstant="2006-07-17T20:31:40Z"> 828 <saml:Issuer 829 Format="urn:oasis:names:tc:SAML:1.1:nameid- 830format:X509SubjectName"> 831 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 832 </saml:Issuer> 833 <saml:Subject> 834 <saml:NameID 835 Format="urn:oasis:names:tc:SAML:1.1:nameid- 836format:X509SubjectName"> 837 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 838 </saml:NameID> 839 </saml:Subject> 840 <saml:AttributeStatement> 841 <saml:Attribute 842 xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" 843 x500:Encoding="LDAP" 844 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 845 Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" 846 FriendlyName="mail"> 847 <saml:AttributeValue 848 xsi:type="xs:string">trscavo@gmail.com</saml:AttributeValue> 849 </saml:Attribute> 850 </saml:AttributeStatement> 851</samlp:ManageAttributeRequest> 8525.3.3 Perceived Technical issue 853The SAML protocol currently provides two methods that enable a service provider to retrieve attributes 854relating to a user from identity provider.: 855• The first method is an attribute push method in which the identity provider can send attribute 856 information within the SAML assertion provided in response to the service provider’s user 857 authentication request. 858• The second method is an attribute pull method in which the service provider can use an 859 AttributeAuthority message or an AttributeQuery message to retrieve information regarding user 860 attributes from the identity provider once the user has been authenticated by the identity provider. 861 91t-soa-uc-pr-01 19 October 2009 92Copyright © OASIS® 2009. All Rights Reserved. Page 31 of 54
  32. 32. 862 In both methods described, the service provider can only obtain information relating to the attributes of 863the user logged into the service provider. 864 There currently exists no mechanism to enable a service provider to transmit user attributes to be 865stored at the identity provider. This contribution identifies the use case of such mechanism. 866 867The issue highlighted in this section aims at possibly extending the SAML specifications. 8685.4 User ID Forwarding 8695.4.1 Scenario/context 870The issue presented in this section derives from a concrete case of activities performed by an operator in 871order to define and implement a “security architecture” for its SOA middleware infrastructure. 872This section addresses potential issues within the OASIS Web Services Security specification ([WS-S 8731.1]. 874Specifically such issues/limitations are related to the necessity of forwarding the User ID across the SOA 875Infrastructure. 8765.4.2 Use Cases 877In order to better describe the potential technical issues, hereafter a use case is presented (ref. Figure 87815), with two possible different example scenarios. The use case is that of a Web Service exposed by an 879Application Provider, and the scenarios are: 880• Customer Care portal accessed by both operator customers and personnel (Call Center Operators), 881 each of them having different “rights” on accessed data. 882• Telco Messenger Service accessed by different MVNOs (Mobile Virtual Network Operators), each of 883 them having different “rights” on accessed data. 884 885Use case Description 886 887 C1 1 2 C1 User 1 3 S11 Credentials User 1 Credentials WSA 4 P1 888 889 Figure 15: User ID Forwarding use case 890 891 1. User 1 accesses a front-end application (C1) using his Credentials (i.e. SSO Token). 94t-soa-uc-pr-01 19 October 2009 95Copyright © OASIS® 2009. All Rights Reserved. Page 32 of 54
  33. 33. 892 2. C1 invokes a Web Service (WS-A) exposed by P1 and passes the User’s credentials (i.e. SAML 893 Assertion) and its credentials (i.e. X.509 Certificate) for XML Encryption and XML Signature (WS- 894 Security 1.1). 895 3. S1 (Security Enforcement Point) handles the invocation message and enforces the AAA policies: 896 a. It validates C1 X.509 Certificate. 897 b. It verifies the XML Encryption and Signature using the public key of C1. 898 c. It verifies if C1 is authenticated & authorized to access the WS-A (C1 X.509 Certificate). 899 d. It verifies if the SAML Assertion and User’s token are still valid. 900 e. It verifies if User 1 is authenticated & authorized to access WS-A. 901 4. P1 (Provider) runs the business logic. 9025.4.2.1 Customer Care portal accessed by both operator customers and 903 personnel (Call Center Operators) 904C1 is a Portal for Customer Caring that consumes a Web Service (WS-A) for retrieving profile information. 905It is used by both Customers (for Self Caring) and Call Center Operators (ref. Figure 16). 906Some of the available information such as: incoming and outgoing calls, personal information or credit 907cards details are ruled by privacy policies. 908Obviously WS-A and all its operations are accessible by C1 but information provided as result or specific 909details depend on the original requester: a Customer could have full access on all information and details 910available on its profile while a Call Center Operator could be granted to view only a subset such data (i.e. 911partial call numbers, filtered credit cards details, etc.). 912In the following scenarios C1 invokes WS-A for retrieving the list of incoming call numbers for specific 913customers: 914 915 C1 6 1 2 1 3 S1 5 C1 Customer Credentials C/C Operator Customer C/C Operator Credentials WS-A Credentials 4 P1 (Master Data) 916 917 Figure 16: User ID Forwarding – “Customer care” use case 918 919 Scenario 1 (Operator’s Customers) 920 1) A Customer accesses C1 to view the list of outcoming calls by using his Credentials (i.e. SSO 921 Token). 922 2) C1 invokes a Web Service (WS-A) exposed by P1 passing the Customer’s credentials in a SAML 923 Assertion and using its X.509 Certificate for XML Encryption and XML Signature (WS-Security 924 1.1). 925 3) S1 (Security Enforcement Point) handles the invocation message and enforces the AAA policies: 926 a. It validates C1 X.509 Certificate, 97t-soa-uc-pr-01 19 October 2009 98Copyright © OASIS® 2009. All Rights Reserved. Page 33 of 54

×