By: Zach Tubb user 27 Sep 2017 at 8:56 a.m. CDT

2 Responses
Zach Tubb gravatar
I'm still reading up on this ticket-issuing-ticket methodology so forgive me if this is a poor question. We have an internet-facing gateway server with all our apps (including gluu) behind the gateway - they don't have internet access. Users hit the gateway and are proxied to an app based on their request, the app then executes SAML authentication with gluu to permit access. Our issue is that we don't want to expose Gluu to the internet but currently Gluu still redirects to client browser and then back to gluu, then sends assertion to the calling app. I tried to get around this by editing the login page action from `prepareToAuthenticate` to `authenticate` (btw gluu is authenticating based on headers from the proxy) but it still wants to go back to the browser. Is there any mechanism we can implement to allow gluu to provide SAML assertions directly back to the application? We are wanting avoid allowing a direct connection from client browser to gluu. Zach

By Michael Schwartz Account Admin 27 Sep 2017 at 3:50 p.m. CDT

Michael Schwartz gravatar
All modern federated identity protocols are based on redirecting the browser to the IDP. The trust originates from an SSL connection between the browser and the IDP. The whole point of these federated authentication protocols is that nothing but the IDP should see the password. TLS is the mechanism to accomplish this. This is especially important if you want to implement authentication that leverages smart cards with mutual TLS or FIDO U2F, which prevent MITM attacks. So the answer is probably... no.

By Zach Tubb user 27 Sep 2017 at 4:56 p.m. CDT

Zach Tubb gravatar
Ok, that was my suspicion and that makes sense. Ultimately you need to authenticate the user's session so Gluu needs to be able to interact with that. Thanks for the confirmation Mike. Zach