Slide title In CAPITALS 50 pt Slide subtitle 32 pt Authentication/Authorization for possible deployments Relevant scenarios for CAFE

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Legenda  Mobile terminal: it means that the Java EE CAFE application is used.  Laptop terminal: it means that in this case the REST CAFE application is used.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Operator B Internet CP/SP Operator A domain CP/SP App 3 NNI CP/SP UNI App 2 Sailfin App 4 Sailfin App 1 IMS Auth Proprietary Auth IMS Auth IMS SIP/XCAP

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Explanation of the previous slide 1.The user is a subscriber of Operator A, so he is registered with IMS credential and it is using SIP signaling and XCAP. The application is provided also by operator A. 2.The user is a subscriber of Operator B and he is registered with IMS credential. Then via secure connection he can use the application that resides in Operator A (due to operators agreements) The others scenarios are depicted better in the following slides.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Internet CP/SP Operator A domain CP/SP App 3 CP/SP Sailfin App 4 Sailfin App 1 IMS Auth Proprietary Auth IMS Auth IMS IMS user ID user ID from Service Provider Proprietary Auth user ID from Service Provider http The APP in CAFE needs to map the proprietary authentication to an IMS authentication. SIP SIP/http

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Explanation of the scenarios 3.The Application resides in the Operator domain and it is a trusted application. The web user is a subscriber of Operator A so it will register with the IMS credentials. 4.The Application is provided by a Service Provider but it is deployed in the operator domain. The Application is trusted, but the Service Provider offers the service to all users, also non IMS users. In this case the Service Provider needs to have a proprietary authentication. Then the Application will use IMS credential for the operator and it would need to map it. 5.The Application is on the Service Provider Domain and it is not trusted. The user cannot use the IMS credentials directly, the Application will map the user to an IMS authenticated user internally. 6.This situation is the same as 3, the only difference is that Sailfin is also on the Service Provider domain.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios Assumption  Charging is not described in the slides. The Application created on CAFE can choose how to charge.  If an Application needs to have a mapping between proprietary authentication and IMS authentication, it can choose how to perform the registration in the IMS network. For example, the Application can request one single IMS user in the operator domain and map it to all users of the Service Provider or it can create a new IMS user for each user of the Application.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson AB 2009CAFFE deployment scenarios