SAML -
安全主张标记语言(英语:Security Assertion Markup Language,简称SAML,发音sam-el[1])是一个基于XML的开源标准数据格式,它在当事方之间交换身份验证和授权数据,尤其是在身份提供者和服务提供者之间交换。SAML是OASIS安全服务技术委员会的一个产品,始于2001年。其最近的主要更新发布于2005年,但协议的增强仍在通过附加的可选标准稳步增加。
SAML解决的最重要的需求是网页浏览器单点登录(SSO)。单点登录在内部网层面比较常见,(例如使用Cookie),但将其扩展到内部网之外则一直存在问题,并使得不可互操作的专有技术激增。(另一种近日解决浏览器单点登录问题的方法是OpenID Connect协议
OAuth -
开放授权(OAuth)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。
OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容。
OAuth是OpenID的一个补充,但是完全不同的服务。
https://duo.com/blog/the-beer-drinkers-guide-to-saml
In SAML lingo, what happened? Let’s start by defining some terms:
Identity Provider (IdP) - The software tool or service (often visualized by a login page and/or dashboard) that performs the authentication; checking usernames and passwords(sync with LDAP), verifying account status, invoking two-factor(Duo-push), etc. This was the Wristband Tent. (i.e. OneLogin)
Service Provider (SP) - The web application where user is trying to gain access. This was the Beer Tent. (All associated Apps on OneLogin)
SAML Assertion - A message asserting a user’s identity and often other attributes, sent over HTTP via browser redirects. This was the wristband itself. (SAML声明-wristbnad)
IdP-initiated versus SP-initiated refers to where the authentication workflow starts. It’s often asked about because some service providers support SP-initiated logins while others don’t. What’s unique about the SP-initiated login is a SAML request.
SP will need to support SAML redirect for SP-Initiated service
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.
A user in your organization uses a client app to request authentication from your organization's IdP.
The IdP authenticates the user against your organization's identity store.
The IdP constructs a SAML assertion with information about the user and sends the assertion to the client app.
The client app calls the AWS STS AssumeRoleWithSAML API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion from IdP.
The API response to the client app includes temporary security credentials.
The client app uses the temporary security credentials to call Amazon S3 API operations.
Before you can use SAML 2.0-based federation as described in the preceding scenario and diagram, you must configure your organization's IdP and your AWS account to trust each other. The general process for configuring this trust is described in the following steps. Inside your organization, you must have an IdP that supports SAML 2.0, like Microsoft Active Directory Federation Service (AD FS, part of Windows Server), Shibboleth, or another compatible SAML 2.0 provider.