There are too many parallel and Symmetric Branch options in the SSO scheme, just like the garden where the boghes side branches. After writing a compact SSO, follow the saml2.0 and openid specifications to record these forks:
- Is the process initiated from the identity Provider or consumer?
The identity Provider, that is, the SSO server, also known as ID provider (IDP. The identity consumer, SSO client, is called SP in SAML.
In the process of initiating the identity Provider, the user logs on to the SSO server. The SSO server displays a portal/menu with several URLs for each SSO client, ID information is added to each URL.
In the process of initiating an identity consumer, the portal/menu is a normal URL without material (or even the user directly goes to the client's website), SSO
The client finds that there is no user identity information in the local session, so it has to redirect to return to the SSO server, and finally the server jumps back with an expected URL.
Apparently, the previous process was redirect twice, which is faster, but every URL in the portal/menu is deeply coupled with SSO sever, or, sometimes there is no such central portal.
- The identity information transmitted in the URL parameter is still a pointer.
?
SSO server direction
When the client jumps, the sender can put the identity information in the URL parameter for direct transmission, or you can carefully throw only one random string (SAML is called
Artifact), the client takes this random string and then secretly asks the SSO server to obtain the complete identity information using the WebService/rest interface in the background.
Obviously, the previous method is faster than the background query, but the latter method is not safe, the WebService/rest interface in the latter way can transmit a lot of information in any format.
- Whether full-text encryption or signature-only security measures
?
Some people like full text (add one moreNonce
) Encryption has been growing for a long period of ciphertext, and our hearts are full of security. Some people also boldly transmit the content in plain text, and only add a signature at the end to prevent counterfeiting (the signature uses simple plaintext + key hashing, or the HMAC encryption hashing algorithm)
In the former, users only see a long period of Mars, which does not give users a glimpse of anything, but the string is violent and encryption and decryption itself consumes a lot of CPU.
- Will the SSO client decrypt/compare the signature by itself?
Generally, the SSO client decrypts or generates a signature based on the plain text for comparison, and verifies that the nonce is not used or has timed out.
However, there may also be a very lazy client. Without such a complicated security encryption algorithm, you can directly send the received content to the SSO server using the WebService/rest interface in the background for help.The SSO is handwritten, And the identity Provider initiates the process. The encrypted identity information is transmitted in the URL parameter, which is decrypted by the SSO client. So, it is super simple...
