我需要创建一些 SAML 2.0 断言，但无法找到 XML 的实际外观。 大多数文档似乎都是关于使用特定工具，而不是关于消息。 我已经有了模式，有很多可能性，但我找不到相关消息在实践中实际是什么样子的示例。
业务规则规定：为了创建共享身份，用户告诉系统 A 他们在系统 B 上的用户名和密码。系统 A 需要将此信息（以及一些人口统计数据）传达给系统 B。系统 B 验证该信息并通过返回一个唯一标识符，然后可以使用该标识符来引用该用户。
有人能给我一个示例，说明携带此信息的 SAML 2.0 断言是什么样子吗？
FWIW，我正在使用 C#，并且需要以排除使用第三方工具的方式传递 XML。
I need to create a some SAML 2.0 assertions, and I'm having trouble finding what the XML should really look like. Most of the documentation seems to be about using particular tools, not about the messages. I've got the schemas, with a plethora of possibilities, but I can't find an example of what the relevant messages actually look like in practice.
The business rule says: in order to create a shared identity, the user tells system A their username and password on system B. System A needs to communicate this info (along with some demographics) to system B. System B validates the information and passes back a unique identifier which can then be used to refer to this user.
Could someone give me an example of what SAML 2.0 assertions would look like to carry this information?
FWIW, I'm using C#, and need to pass the XML around in ways which preclude using a 3rd-party tool.
发布评论
评论（1）
我不确定您的用例是否与 SAML 2.0 完全一样。
您所描述的业务规则实际上看起来像是身份配置的用例，而不是访问管理的用例。
标准 SAML 2.0 用例侧重于声明身份的一方（身份提供商）和依赖这些声明的另一方（或多方）（服务提供商）。 断言携带所谓的名称标识符，其使用由身份提供者和服务提供者提前商定。
这些名称标识符几乎可以是任何东西，但它们大致分为两类：瞬态和持久。 临时名称标识符仅在当前会话的上下文中有用（本质上仅表示“我知道这个人是谁”），并且往往用于保护主体的身份，同时允许某种类型的特权访问。 持久标识符可以是不透明的（与使用 OpenID 访问 SO 的方式类似），其中断言方可以重复验证主体的身份而无需公开其身份，同时在断言方和依赖方之间维护动态但稳定的共享标识符，或者更重要的是，例如 Active Directory UPN（可以提前预先商定）。
当谈到密码时，正如您在问题中提到的，服务提供商（依赖方）永远不会看到用户的密码。 服务提供商将用户通过身份验证请求移交给身份提供商。 身份提供者将用户连同响应发送回服务提供者，在身份验证成功的情况下，该响应包含关于在身份提供者和服务提供者之间的关系的上下文中的用户身份的断言。
就您的问题而言，最重要的是 SAML 2.0 没有提供创建本地“应用程序”用户帐户或将该本地用户帐户链接到联合身份的方法。 这根本不是 SAML 2.0 试图解决的问题。
现在，回到您的业务规则...
在我看来，您想要做的是帐户链接或注册 - 我会这样处理：
至于消息的内容...
OASIS 安全服务技术委员会< /a> 有一个 zip 文件下载，其中包含 XML 模式各部分的大量文档，包括示例。 协议和配置文件文档也非常值得阅读，因为它们描述了身份对话中涉及的各方之间的消息流。
有大量我发现非常有用的演示文稿。 具体来说， Eve Maler 的 SAML v2.0 基础知识帮助我开始意识到 SAML v2.0 试图解决什么问题。 本演示文稿包含断言的示例。 saml.xml.org 上有更新的演示文稿和其他资源的链接。
我不确定这是否有帮助，因为您的用例似乎不是 SAML 2.0 想要做的事情。 您可以根据需要向请求和响应添加属性和扩展，但我看不到许多身份提供者对这些属性和响应执行任何操作。
I'm not sure your use case is quite what SAML 2.0 does.
What you describe as your business rules actually looks like a use case for identity provisioning, not access management.
Standard SAML 2.0 use cases focus on one party asserting identity (the identity provider) and the other party (or parties) relying on those assertions (the service provider). Assertions carry what's called a name identifier, use of which is agreed ahead of time between the identity provider and the service provider.
These name identifiers can be pretty much anything, but they broadly fall into two categories: transient and persistent. A transient name identifier is only useful in the context of the current session (and essentially only says, "I know who this person is") and tends to be used to protect the identity of the principal while allowing privileged access of some type. A persistent identifier can either be opaque (in a similar way to how OpenID is used to access SO) where the asserting party can repeatedly verify a principle's identity without disclosing their identity while maintaining a dynamic but stable shared identifier between the asserting and relying parties or more substantial, such as an Active Directory UPN (which can be pre-agreed ahead of time).
When it comes to passwords, as you mention in your question, the service provider (relying party) never sees the users password. The service provider hands the user over to the identity provider with an authentication request. The identity provider sends the user back to the service provider with a response, which in the case of successful authentication contains an assertion about the identity of the user in the context of the relationship between the identity provider and the service provider.
In context of your question, the big thing is that SAML 2.0 does not provide a way to either create the local "application" user account or link that local user account to a federated identity. This is simply not the problem SAML 2.0 tries to solve.
Now, back to your business rules...
It looks to me like what you're trying to do is either account linking or registration - I would approach it like this:
As for the content of the messages...
The OASIS Security Services Technical Committee has a zip file download available with extensive documentation of the parts of the XML schema, including examples. It's also well worthwhile reading the protocol and profile documentation, as these describe the flow of messages between the parties involved in the identity conversation.
There are a large number of presentations floating around that I found very useful. Specifically, SAML v2.0 Basics by Eve Maler helped me start realising what problems SAML v2.0 was trying to solve. This presentation includes examples of that assertions look like. There is an updated presentation and links to additional resources on saml.xml.org.
I'm not sure if any of this is going to help though, as your use case does not seem to be what SAML 2.0 is trying to do. You can add attributes and extensions as needed to requests and responses, but I can't see many identity providers doing anything with those attributes and responses.