SAML , OAUTH

 SAML VS OAUTH:

https://www.parallels.com/blogs/ras/saml-vs-oauth/#:~:text=Security%20Assertion%20Markup%20Language%20(SAML,binary%2C%20or%20even%20SAML%20formats.

https://duo.com/blog/the-beer-drinkers-guide-to-saml#:~:text=SAML%20%2D%20Most%20commonly%20used%20by,user%20is%3B%20this%20is%20authentication.

SAML XML response example :

https://www.samltool.com/generic_sso_res.php

JS XML Parser:

https://www.w3schools.com/xml/xml_parser.asp

https://stackoverflow.com/questions/17604071/parse-xml-using-javascript

SAML IDP(business user belong), SAML SP(Sales force),

so when user logs into business (SAML IDP), SAML XML send to SP (sales force) so user dont need to login again on sales force: 

configration https://duo.com/blog/the-beer-drinkers-guide-to-saml#:~:text=SAML%20%2D%20Most%20commonly%20used%20by,user%20is%3B%20this%20is%20authentication. :

Configuring SAML

We’ve covered the basics of what SAML is, how logging in with SAML works, and a few of the most common SAML scenarios. Now, let’s talk configuration specifics: setting up the tents.

Configuration for SAML must be done in two places: at the IdP and at the SP.

The IdP needs to be configured so it knows where and how to send users when they want to log in to a specific SP. This is like setting up the Wristband Tent and making sure its workers know they’re checking IDs so that people can be served beer (and that they shouldn’t let minors have a wristband), and after they issue a wristband to point people toward the Beer Tent (rather than, say, a T-shirt Tent or out of the concert venue).

The SP needs to be configured so it knows it can trust SAML assertions signed by the IdP. This is like setting up the Beer Tent and making sure its workers know to look for wristbands that match the wristbands that their trusted Wristband Tent are issuing (as opposed to a friendship bracelet someone just happens to be wearing).

IdP Configuration

Specifications for a SAML assertion - what it should contain and how it should be formatted - are provided by the SP and set at the IdP. This is like the Beer Tent dictating what they expect to be on a wristband and the Wristband Tent being made aware of those expectations.

The following values must be set at the IdP for each SP, and there’s often quite a few of them. This is like a Beer Tent, a Whiskey Tent and a Wine Tent all trusting the same Wristband Tent. Often, IdP products can set these automatically behind the scenes, but as an admin you’ll need to provide at least some of this information:

EntityID - A globally unique name for the SP. Formats vary, but it’s increasingly common to see this value formatted as a URL.

• Real Example: <EntityDescriptor entityID="https://beertent.com/concert">
• Beer Example: “Greg’s Concert Beers”

Assertion Consumer Service (ACS) - The URL location where the SAML assertion is sent.

• Real Example: https://beertent.com/saml/consume/
• Beer Example: “Arrive at the left side of the Beer Tent. That’s where the line starts.”

ACS Validator - A security measure in the form of a regular expression (regex) that ensures the SAML assertion is sent to the correct ACS. This only comes into play during SP-initiated logins where the SAML request contains an ACS location, so this ACS validator would ensure that the SAML request-provided ACS location is legitimate.

• Real Example: ^https:\/\/beertent\.com\/saml\/consume\/$
• Beer Example: “Make sure you’re going to this Beer Tent and not some other tent.”

Attributes - The number of and format of attributes can vary greatly. There’s usually at least one attribute, the nameID, which is typically the username of the user trying to log in.

• Real Examples:
  NameID Format
  NameID Attribute

• Beer Examples:
  “The wristband shows your name is Bob Boozer.”
  “The wristband shows that was your first name and your last name.”

RelayState - Not required. Deep linking for SAML. This tells the SP where to take the user once they’ve successfully logged in.

• Real Example: https://beertent.com/taps/lager/
• Beer Example: “After the Beer Tent approves of your wristband, ask for a lager.”

SAML Signature Algorithm - SHA-1 or SHA-256. Less commonly SHA-384 or SHA-512. This algorithm is used in conjunction with the X.509 certificate mentioned below.

• Real Example: SHA-256
• Beer Example: “The wristband has a hologram, so you know it’s real.”

SP Configuration

The reverse of the section above, this section speaks to information provided by the IdP and set at the SP. This would be the information we provide to the Beer Tent to give them a way to validate that the wristbands drinkers arrive with were truly issued by the Wristband Tent they trust.

X.509 Certificate - A certificate provided by the IdP, used to verify the public key as passed by the IdP in the metadata of the SAML assertion. It allows the SP to verify the SAML assertion is actually coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed. Typically, it’s downloaded or copied from the IdP and configured by uploading or pasting it to into the SP.

Issuer URL - Unique identifier of the IdP. Formatted as a URL containing information about the IdP so the SP can validate that the SAML assertions it receives are issued from the correct IdP.

• Real Example: <saml:Issuer>https://access.wristbandtent.com/saml2/idp/metadata.php</saml:Issuer>
• Beer Example: “Only accept SAML assertions that are issued from a Wristband Tent that matches this description.”

SAML SSO Endpoint / Service Provider Login URL - An IdP endpoint that initiates authentication when redirected here by the SP with a SAML request.

SAML SLO (Single Log-out) Endpoint - An IdP endpoint that will close the user’s IdP session when redirected here by the SP, typically after the user clicks “Log out.”

• Real Example: https://access.wristbandtent.com/logout
• Beer Example: “Go to this location at the Wristband Tent to have your wristband removed.”

How Is SAML Different From Oauth and Web Services Federation?

We hear about these other SAML alternatives in passing, but how do they differ? Should you have an opinion on which one is best? Understand that SAML, OAuth, and Web Services Federation (WS-Fed) all vary technically, as well as how they’re best put to use.

• SAML - Most commonly used by businesses to allow their users to access services they pay for. Salesforce, Gmail, Box and Expensify are all examples of service providers an employee would gain access to after a SAML login. SAML asserts to the service provider who the user is; this is authentication.

• WS-Fed - Web Services Federation is used for the same purposes as SAML, to federate authentication from service providers to a common identity provider. It’s well supported with certain IdPs, like Microsoft Active Directory Federation Services (AD FS), but it’s not prevalent with cloud service providers. WS-Fed is arguably simpler than SAML for developers to implement, but its limited support among IdPs and SPs alike make it a tough sell.

• OAuth - Most commonly used by consumer apps and services so users don’t have to sign up for a new username and password. “Sign in with Google” and “Log in with Facebook” are examples of OAuth in the real world. OAuth delegates access to a person’s Google or Facebook account by a third party.

Typically the app the user is signing into can directly read information from the user’s profile or take actions (like post pictures or make updates) on their behalf; this is authorization. This would be like going to the Beer Tent and instead of the Beer Tent sending Bob to the Wristband Tent, they ask Bob to hand them his ID and sign off that the Beer Tent workers can go over to the Wristband Tent on his behalf and represent him; he is authorizing them.

What’s more important is to look at prevalence of each technology for each use case. SAML is ubiquitous in the workplace for cloud-based apps, while WS-Fed is not. Conversely, OAuth is ubiquitous among consumer apps.