1

2Telecom SOA Use Cases and Issues
3Version 1.0

4Committee                 Draft 01
56   October 2009
 6
 7Specificatio...
40         All perceived technical issues on SOA standards contained in this document are structured with a
41         des...
62Notices

 63Copyright © OASIS® 2009. All Rights Reserved.
 64All capitalized terms in the following text have the meanin...
108Table            of Contents
1091   Introduction..........................................................................
151         6.3.1 Perceived Technical Issues.................................................................................
166Table             of Figures
167
168Figure 1: Reference Schema to classify SOA subject areas..............................
1941    Introduction
195
196Service-Oriented Architecture, SOA, is a design approach that divides everyday business applic...
237

2381.1 Terminology
239The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD
240NOT”, ...
288

2891.3 Non-Normative References
290
291    [WS Landscape]              Possible representation of web services specif...
2932    Context setting
294This section provides a rationale for the classification of the issues presented in the documen...
308
309The list of received contributions is presented hereafter, while in Figure 2 a mapping of the contributions
310to t...
33510. Universal Communications Profile, related to the specification of a possible common profile for
336    universal in...
3513    Issues on Addressing and Notification
352

3533.1 Transaction Endpoints Specification

3543.1.1 Scenario/context
3...
379

                                                                      c2
                    c1                      ...
385Use Case Steps:
386Case A
387    •    C1 invokes WSA, exposed by ESB.
388    •    WSA is executed with the internal com...
427
428
429Use Case Steps:
430    1. The Application informs the Provider that it wants to be notified when the specified ...
451
452Such lack is perceived as a strong market gap with negative impacts for both Telecom Operators and
453Third Parties...
484
485
486                                      Figure 6: Notification use case (b) flow
487

4883.2.5 Perceived Technica...
5044       Issues on communications protocols
505

5064.1 SOAP

5074.1.1 Scenario/context
508The issue presented in this s...
536The access point for the Consumer C1 is the ESB, which exposes such Web Service and moreover
537executes some of its ty...
554
          <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-
          ENC="htt...
569      The Data Enrichment task is executed with the collaboration of other “Service Providers” (different
570      than...
596
597
       <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-
598    ENC="http:...
621Table 2 defines three role names which have special significance in a SOAP message (see 2.6
622Processing SOAP Messages...
643The perceived technical gap suggested by the operator is that the SOAP specification should be modified
644in order to ...
6555    Issues on Security
656

6575.1 SAML Token Correlation

6585.1.1 Scenario/context
659The issue presented in this se...
685
                                       CRM                                      BPM                                 De...
692
693Use Case steps.
694•    The CRM sends an ADSL activation request.
695•    The consumer (CRM) provides its credentia...
740           874 specification.
741--------
742
743Thus, form a syntactical perspective, the specification enables the “c...
783user device. The IdP requests a name identifier from the SP, who sends the desired name identifier to the
784IdP.
785
7...
814    5) Upon receipt of the Name Identifier Request, the SP recognises that the IdP does not have an
815       identifie...
857so the service provider will not be able to link the attributes for a user’s temporary account with the user’s
858perma...
879    Format="urn:oasis:names:tc:SAML:1.1:nameid-
880format:X509SubjectName">
881    C=US, O=NCSA-TEST, OU=User, CN=trsca...
9215.4 User ID Forwarding

9225.4.1 Scenario/context
923The issue presented in this section derives from a concrete case o...
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
OASIS Specification Template
Upcoming SlideShare
Loading in …5
×

OASIS Specification Template

833 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
833
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OASIS Specification Template

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

×