Today Portal and partner apps support single sign-on via cookies.  The portal sets a cookie on a domain name with a well-known suffix, redirects user's browser to the app URL, the app recognizes the cookie and establishes a session, and the user is logged in. However cookies need domain names (not IP addy) and those names cause nontrivial deployment challenges.

Instead:

1. Enhance Portal's initial handover to an app.  It should generate a user-identifying token, encrypt the token with the Portal private key, and redirect the user to a new app endpoint incorporating that data in the URL.

2. Enhance SDK with an endpoint that gathers the data sent, decrypts the data with the Portal public key to obtain the token, extract appropriate user details from the token, and create a session for the user.

Because the ONAP Portal team controls the sender (portal) and receiver (app), I think this is within their power to implement. Hopefully the only changes required by partner apps will be additional configuration such as enabling this endpoint and storing a copy of the Portal public key.

If this is implemented, then the current requirement that all ONAP apps use names within a single domain (e.g., "portal.api.simpledemo.onap.org") can almost certainly be dropped.