Computing desk
< February 18	<< Jan \| February \| Mar >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 19

Automatic PAM to IBM authentication with DPI in between

I'm trying to find technical descriptions of the following scenario. Org has a basic IBM TAM for SSO. That is local. They also have DPI for all traffic leaving the local network. A webserver (or any server) is on the cloud, obviously outside the local network. That server authenticates through the internal IBM TAM using PAM. A user goes to a web page or something that requires authentication and, seamlessly, it authenticates because the user already logged into the SSO from their local computer inside the org. How is it seamless? The traffic from the local computer to the cloud server is going through DPI, so all the identify of the originating computer gets mutilated. The public/private key exchange is broken because DPI acts as MITM. When the cloud server authenticates with SSO, it must have some form of token to validate, which assumes that the user's computer sent the token. Why would it? Why would going to a web page include sending a token and how would the token remain intact through DPI? I expect the user to hit the external server and have to go to the SSO login page, login again, and then use the server. I also expect that any automated login process would be blocked because all of the org's traffic comes from the DPI box. So, if anyone can point me to some technical documents that describe exactly how this seamless authentication takes place, I would appreciate it. 12.116.29.106 (talk) 15:16, 19 February 2025 (UTC)[reply]

To editor 12.116.29.106: Hmm... I think I understand the scenario you're asking about. If I'm right, then you were in fact on-track with the observation about the man-in-the-middle! Usually what is done on corporate intranets is, the corp has their own SSL certificates, which they add to the trusted keystore of all their internal systems. "Outgoing" network traffic from inside the intranet usually is proxied to "exit" servers, and SSL/TLS connections go to the exit proxy using that intranet certificate, which acts as a "man-in-the-middle" relaying internal traffic to the outside Internet, unwrapping SSL traffic and rewrapping it as-needed.

The corp already has total physical control of all the systems, which they own; there's no "loss of security" here. It's their house, their rules. For any org of decent size all this stuff, such as installing their intranet certs, will all be automated as part of system provisoning and internal network authentication and access control. If they're doing security well, they won't even allow any network traffic on the corporate intranet that's not from a client authenticated using 802.1x stuff as an authorized client. This guards against stuff such as network snooping from nefarious actors who pay a visit to the place and hook someting up to an out-of-the-way network jack in a closet somewhere. --Slowking Man (talk) 22:48, 23 February 2025 (UTC)[reply]

Thank you. Assume that I am inside the corporate network, logged in, and I go to some website owned by the corporation, but well outside their network. How does it automatically log me in? I know the remote website uses the local SSO for authentication. I know the local SSO has be registered as logged in on my local computer. I am trying to see how the remote website talks to the SSO to work out that I am me and I am logged into the computer that is accessing the website and I should be given access to the website. I am now reading about SAML, which I haven't researched much in the past. 12.116.29.106 (talk) 13:44, 25 February 2025 (UTC)[reply]

It appears now that it is a bit more of a back and forth. User goes to remote website. Remote website asks the user for an authentication key. User doesn't have one yet because user just showed up. remote website redirects user to the internal SSO. The internal SSO checks login status and asks the user to log in if necessary. then, the internal SSO gives the user an access key and redirects the user to the remote website. The remote website asks for an authentication key. The user gives it. The remote website asks the internal SSO if the key is valid. It says yes and sends the pertinent user information back to the remote website. The remote website knows the user is logged in and displays whatever it is supposed to display. I had incorrectly assumed that the remote website talked directly to the SSO on hehalf of the user. It doesn't. It redirects the user. 12.116.29.106 (talk) 17:20, 25 February 2025 (UTC)[reply]

Yeah, the exact details can vary depending on how they have their internal networks and everything set up, but that's a pretty common scheme. Their website host sees you are traffic from their intranet and sends you to the internal auth gateway. In fact, again depending on how they do stuff it's possible your traffic never even passes over the public Internet—they could their own direct connections into their website hosts and have routing inside the intranet configured so it routes traffic from within the intranet going to example.com (if that were their public website address) across those direct links. Anyway however it's set up, the example.com servers see that you're intranet-originated traffic and send you to the internal auth gateway. Internal gateway gives you credentials, you present those to example.com, then example.com in its backend checks for verification the credential is legit. For reference: SAML --Slowking Man (talk) 00:57, 27 February 2025 (UTC)[reply]