Identity Management at NodeJS

[pchainho]

Following https://github.com/reTHINK-project/dev-runtime-core/issues/96

Summary:

@jmcrom: We must have a way to configure the identity locally as a local assertion on the server. We may need some remote API also, mostly for objects that have their identity instantiated on a gateway (i.e. edge server)

@pchainho: A more complete solution would be to use Browser Runtime admin GUI to manage identities in remote NodeJS servers. There would be the notion of runtime accounts where we could distinguish two roles: administrators and customers. Administrators manages customer accounts.

[jboulmal]

Today, on #runtime-nodejs we only have temporary fix identity in runtime-nodejs, the identity of user behind the server-hyperty is a static number generated by runtime. Just doing quick search may be we can use google-api-nodejs-client mechanism.

[jboulmal]

For the time being and for simplicity also, we can go with your idea @pchainho having runtime browser GUI but does this mean that it should be features of runtime browser or runtime core, that can distinguish both environment ? or may be in runtime nodejs we open browser GUI, in order to assert identity of the user behind the hyperty ?

[jboulmal]

Today, the identity of user behind the server-hyperty is a static identity asserted locally on the runtimeUA.

Here are some points collected form previous issues on this topic :

• Remote API for administration purpose : Remotely manage Identity Tokens in the Identity Module, eg to expose some Identity Module API through a remote API.
• Browser Runtime admin GUI to manage identities in remote NodeJS servers.

[jboulmal]

In our last meeting, we had an interesting discussion about the identity management from the security experts in reTHINK. Since I haven't taken note. I hope that @Ricardo-Chaves, @jmcrom, and @gamdias can share here thier contributions and scenarios ?

[jmcrom]

in Lisbon we investigated 2 options for settiing the identity of server-side hyperty throgh the example of a multimedia conference :

1. identity derivated from the identity of the user creating the conference: then the server-side service needs to get an authorization from this very user (through for instance some OAuth token), this implemntation reqires additional development to get this authorization

2. identity of the server-side service with some reference of the user identity (display name): mch easier to implement yet implicating some trust relationship between the ser creating the conference and the SP providing this service

we should describe both options then implement only one

[jboulmal]

Thanks for the contribution @jmcrom, I'm OK with implementation n° 2 for now. Since I think that option n° 1 requires some changes on the runtime, right @Ricardo-Chaves, @jmcrom, @gamdias , @KCorre ?

[Ricardo-Chaves]

Option nº2 does not require much change (if any).

Option nº1 does require much change in the way the identities are managed and used and may not even be possible in some cases (such as when the private element is not managed by the IdM). In my opinion it also raise some concerns in terms of security, given that the server will be in possession of some of the users private values.

[Sparika]

Do you have a diagram of some sort to show how the different users and a server side hyperty relate to each others?

[jboulmal]

Here @KCorre (alias @Sparika) is a scenario example of rethink WebRTC group communication : https://github.com/reTHINK-project/specs/tree/master/group-communication see last figure : reTHINK Group cummunication overall architecture

[KCorre]

Ok, thanks. Just a note, the media server should be in the same grey box as the Node Server.

The room's identity is not the same as its creator's identity. For me the room obviously does not need to authenticate, so it could generate an identity assertion by itself. The room creator's identity is for me application related, not runtime related. But it could be included in the room identity with something like: room42-Alice@com-service. But IMHO, an identity assertion for the node server is enough (com-service.com).

Anyway, it needs to be its own IdP Proxy provider, because google is not going to generate gmail accounts for each room. ;)

[jmcrom]

@pchainho @Ricardo-Chaves could you describe what you are implementing to address this issue?

[pchainho]

It is ongoing at https://github.com/reTHINK-project/dev-runtime-core/issues/149 with an hardcoded id token.

I guess anyone can then provide its one "real" IdP Proxy that is able to interact with some nodejs enabled IdP to get the id token