Identities from legacy domains

[pchainho]

The current specs to support interoperability with legacy domains proposes the possibility to associate a second legacy identity to hyperties when interworking with legacy services.

One option could be not to associate this second legacy identity during deploy time but only when the Hyperty is interworking with legacy services. It would require from the IdM:

• to have identities associated with legacy domains: let's call it "Legacy Identities"
• when the outgoing message is targeting the legacy domain, such "legacy identity" would prevail against the identity associated with sender hyperty

[sbecot]

You may think I'm again not very kind, but probably it would be wise to finish the ongoing work about identity before going to new developments.
Currently there is no possibility to select an identity other than google one, the graph connector isn't available, the Idps of Orange have not been used/integrated.

[jmcrom]

I agree with @sbecot and I think the main legacy interworking (IMS) may be addressed in D6.2.

Abot the architecture displayed in the dedicated page I have multiple questions: what exactly is IWStub ? some kind of ProtoStub ? where does it come from ? what impact on the "legacy domain" ? what is IWHyperty ?

[pchainho]

these are specs for phase 2 and we are analysing the impact of legacy interworking in the core framework.

[emmelmann-fokus]

I support @sbecot, we should finish the functionality of existing areas before going into new domains. @aoncorici is driving the interoperability issue for D6.2 sufficiently. Any additional work items should follow solutions for having more than one identity provider.

[pchainho]

@emmelmann-fokus these are only specs and, as previously agreed, this is a topic to be included in D3.5 to analyse the impact of legacy interworking in the core framework. This has been a joint work between WP3 and WP6.

[Ricardo-Chaves]

The IDM component (regarding phase 1) is basically done.
It accepts/uses IDs from google am MS. Other OIDC compatible IdP can be (with relative ease) integrated.

Nevetheless, I agree that interoperability with legacy domains should be left for D6.2. There are many aspects that are unclear to me at the moment, related with the how to interact with legacy domains via rethink, and I suspect that many issues will appear that need to be thought and discussed to solved them.

Definitely to be discussed in the coming meeting.

[pchainho]

@Ricardo-Chaves there is an impact on the Core Framework and namely on the Core Runtime that we should take into account in D3.5.

We should not leave the discussion for the F2F meeting. I'm afraid that would be too late.

The high level view of the integration seems clear too me (pls see here ) but of course it still requires to be completed as noted by @jmcrom .

[jmcrom]

@pchainho given my concerns (see this issue) I would not say the high level view is clear

@Ricardo-Chaves I do not see any Identity GUI

[pchainho]

@jmcrom just check my comments :)

[gamdias]

@jmcrom The identity GUI is in this pull request reTHINK-project/dev-runtime-browser#57

There is a problem in the Runtime-browser that cannot use the new Runtime Core distributions. Because the identity GUI requires the new runtime core distribution, the example fails.
David is taking care of the issue and as soon as it is fixed I provide the instructions to run the example with the identity GUI.

[pchainho]

Here is the proposal that fully reuses the existing IDM mechanisms and thus have a minimum impact in terms of development:

1- the GUI Manager is used to authenticate and generate access tokens for Legacy Domains. This would trigger the deployment of a IWIdPProxy that would be used to generate the access token to be handled by the IDM.

2- when routing messages to protostubs, the IDM/Policy Engine verifies the target is a legacy domain ie IWStub, and it doesn't use the mutual authentication process. Instead, it adds an access token that was previously generated. If there is no access token yet, step 1 is performed ie the deployment of IWIdPProxy and the generation of the access token is performed.

[pchainho]

In terms of implementation tasks we have:

• add a boolean attribute "interworking" to IdpProxy descriptor: no change to specs since idp proxy descriptors is an extension of protostubs descriptors.
• adapt the IDM to deal with access tokens for Interworking IdP Proxies
• adapt the IDM to add access tokens when messages are forwarded to Interworking Protostubs
• implement IW IdP Proxy having as starting point an IdPProxy template

[Sparika]

It's not the GUI that authenticates the user, it only provides the means to select an identity. Similarly, the GUI can't 'generate token' because they must be signed by an a trusted service (Authorization Server in case of Access Token, though I'm not sure why you want access tokens).

There is two main functions, generation and verifications of identity assertions. And there is two scenarios, either the function is executed on the standard reThink side, or the function is executed on the legacy side.

If either functions are done on the standard reThink side, nothing changes. You want to generate an assertion, you call the selected IdP Proxy, you want to verify it, you call the provided IdP Proxy. tl;dr; nothing to change on the runtime

However, what changes is when one of these functions is done on the legacy side. From what I understand, there are no runtime on the IW side (IMS?). So the generation and verification of assertions must be done by IMS components responsible for this kind of functions.

http://fr.slideshare.net/Quobis/security-and-identity-management-on-webrtc
Annex C and D of the presentation are dealing with that issue. Since I'm not familiar with IMS, I don't know the meaning of the 'WAC' component interacting with the Gateway or what are other components. Maybe @jmcrom can comment. I think that @baldystef was also working on WebRTC-IMS integration and maybe published something?

BTW, these slides are made by Quobis @antonroman.

[jmcrom]

on the IMS part I have 2 comments:

• first, the diagram is not explicit enogh: at least it should show the gateway(s) the text is talking abot, since it is the component that make interworking possible
• second, as I wrote earlier, it would be nice to refer to the functions deecribed in the referenced 3gpp spec to make it clearer to IMS people

@Sparika to my knowledge WAC is a product made by Quobis to interoperatie with existing communications systems (see here). I wonder how it maps to WWSF... @antonroman should know better

[rebecca-copeland]

We worked on this (Ibrahim and me) in the IETF draft, but cut it out in the end to shorten it.
1, The WIC (WebRTC IMS Client) must be in the handset. See 3GPP TS 24.371. Without this, you cannot reach the P-CSCF.
2. There should be an ordinary single-sided authentication of the identity by the IdP that the service provider (MNO or MVNO) is happy with. The identity could be an IMS identity - a telephone number - that has been already allocated. There is no need to exchange tokens except where this authentication is not internal to the CSP, but using an IdP. Note: this is NOT the same as webRTC authentication between users, with IdP proxies at both parties.
3. The service provider has a pool of IMS identities. The CSP allocates an IMS identity, temporarily or permanently to the authenticated web identity. Only then, the user can be recognised by IMS.
4. You won't be able to test that in real networks, unless you have an MNO that can allocate IMS IDs...

In a previous IETF Draft we had the following:
WebRTC browser-based calling services needs to communicate with non-browser entities, including users of IMS (IP Multimedia Subsystem) or EPC (Evolved Packet Core) networks. The interworking should not be only at the level of signaling and applications, but also at the authentication stage. With one user having an IdP based identity that relies on peer-to-peer authentication, and the other having IMPU/IMPI (public/private) identity centralized structure, neither methods can provide fully mutual authentication. Hence, an alternative process is needed.

Interconnection of WebRTC services with IMS network is specified by 3GPP in [3GPP TS 24.371] which is now included in the main IP Multimedia Subsystem (IMS) architecture [3GPP TS 23.228]. This document specifies the WIC (WebRTC IMS Client) which is installed at the device, enabling it to contact the local eP-CSCF, and access the IMS system. However, the IMS authentication requires that WebRTC CS users are allocated IMS identities, temporarily or permanently. IMS and WebRTC services need to interwork in two ways:

• Initiating and receiving calls between IMS users and WebRTC CS users.
• CS making use of IMS authentication, whether calling IMS or not.

To use IMS procedures to authenticate WebRTC CS users who do not have existing IMS accounts, they should be assigned IMS identities. Their IdP identity is authenticated first. Then, the CS assigns an IMS public number (IMPU) that is associated with the user's private number (IMPI). These identities are supplied by the CS from a pool of valid MSISDN numbers that an IMS operator has allocated to the CS. With the allocated IMS identities and the WIC client, users can be authenticated by IMS standard procedures, whether they connect to IMS or to other WebRTC users.

[pchainho]

@Sparika I think we are aligned, no major changes are needed in the runtime for your 1st option. However I understood that at this point, the IdP Proxy / IDM are only able to handle Id Tokens and not Access Tokens. But perhaps I'm wrong and @gamdias can clarify on this.

[pchainho]

As agreed today:

1- Discover the GUID from the Global Discovery by using some user identifier
2- If result is "not found", somewhere in the runtime or in the global registry (to be decided), a IW Sub catalogue URL is derived from the user identifier.
3- the runtime configuration contains the fallback catalogue and also the order it is used.
4- for "protocol://user@domain" the domain of the service provider would be "domain" and the standard catalogue URL is derived from it as it is done for any other reTHINK domain.
5- for the fallback catalogue URL it would be derived like: <fallback-catalogue-domain>/.well-known/protocolstub/<protocol>.<domain>

[aoncorici]

thank you :)

[rjflp]

@pchainho For the 5th point is it really ".../.well-known/protocolstub/."? Shouldn't it be ".../.well-known/protocolstub/"?

[sbecot]

For the point 2 I think we should add the possibility to add non-rethink identities. This way, the identity model can be applied to any legacy application (sip or Web), etc...

[jmcrom]

following Lisbon meeting I drafted this to map reTHINK concepts to functional entities introduced in 3GPP TS 24.371

any feelings?

[aoncorici]

dear Jean-Michel, thank you for the diagram, I will have to check what the equivalent of WWSF is in out case. Can you please upload the source of the diagram on: https://github.com/reTHINK-project/testbeds/tree/master/docs/D6.2.

[jmcrom]

done! it's called IMSinterop.pptx