0

I am thinking how to gain and analyze the information in the real SSO (request/response) messages, for some commercial SSO solutions.

The challenge is that most commercial SSO solutions are black-box or gray-box. I know the OpenID/SAML protocols. Based on these standards, SSO vendors(idps) customized their own SSO solutions, such as Google ID SSO, Paypal Access SSO, Facebook Connect SSO, and many more.

  1. As the SSO token/assertion is transmitted through network, is it possible to analyze them (SSO request/response messages) by the help of network sniffing?

  2. I know many of them are already encrypted by TLS/HTTPS. Is it possible to turn them into HTTP and analyze?

  3. Any other methodology can help commercial SSO's analysis, except searching official whitepapers online? For example, browser-based analysis.

TJCLK
  • 818
  • 8
  • 23
  • I am not sure I understand what you are after. You can of course use any SSO system yourself (e.g. enroll in Google Plus) and view the traffic without needing to do any sniffing. What are you hoping to gain by viewing the requests and responses? – John Wu Mar 01 '17 at 03:50
  • @john: i think quite a lot, e.g. sso version, expiration date, many payload attributes, signatures, in the sso request/response – TJCLK Mar 01 '17 at 03:58
  • the objective is to understand commercial SSO detailed specification of operations – TJCLK Mar 01 '17 at 04:02

1 Answers1

2

There are two types of data in an SSO system: data an end user can see and data that is hidden from the end user. If the system is designed properly, there is no third category (i.e. there is no data is hidden but obtainable via sniffing).

There are many SSO systems where 100% of the data transfer is done right before your eyes, in the browser. If you have Chrome you can hit F12 and see all of the traffic. You don't have to sniff it or decrypt it because you are the proper user and your browser has the cryptographic session key. With this method, you can see often SAML requests, responses, and assertions passing right through your browser via scripted posts and redirects.

But in some systems there are data that are hidden, via two means. (1) The data still flow through your browser, but are encrypted (e.g. a session cookie containing an encrypted bearer token), and (2) data that flow through a back channel (e.g. if a private VPN is established between the identity server and the application server). In the former case, you will not be able to access the data unless their crypto is broken. In the latter case your browser may be using tokens that are meaningless to you because they are pointers into a data store that you can't see.

In all cases, sniffing network traffic won't get you anything that you can't get by easier means.

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • hence, it does not matter https or http, because "brower has the cryp session key", right? Btw, I just Google searched "Chrome SAML debugger", i guess they also designed to trace SAML request/response? – TJCLK Mar 01 '17 at 09:03
  • Don't think it has SAML-specific tools, but you can often see the SAML stuff in the request/response header/body in plaintext, or base64-encoded. – John Wu Mar 01 '17 at 09:09