A few points I would like to get some clarity on. When you say Web Server, are you referring a simple Apache HTTPd Server...or are you talking about some sort of Application Server?
It sounds like you are trying to proxy information from the Web Server to Jive via an Add-On Experience. If so, then if you are trying to keep identity context then you only have a few options. Hoping one of these helps.
- Create a proxy service that respects the Jive App authz signing, which can then translate identity and interact with the web server as the desired context. This will prevent a username/password from being exchanged.
- Create a Jive App that leverages Jive Connects that asks the user to login/confirm identity once...and then Jive Connects maintains further identity connections with your server.
I think one of the biggest items here, is that it is recommended that you focus on integrating at an API/data level ... and not try to serve up existing experiences inside Jive that are bound by external sessions.
Does any of that help? =)
yes we are talking about a tomcat servlet container as web server, which will retrieve data from external sources. To collect the right data we need the identity from the user authenticated through Jive. I will pass your information to Ronny Göstenmeier and Kai Paroth and I think with some additional clarification they should be able to solve this issue.
If you implement your own end-point to be called from Jive, you can leverage the authz signing which can be validated on your end to be from a valid Jive instance. The signing includes the userID, username and the Jive instance (plus a few more details) that will help you look up the user in a shared IDP or what not.
There are examples of this in the node.js and Java Jersey SDKs if I am not mistaken.