我不确定您的用例是否与 SAML 2.0 完全一样。
您所描述的业务规则实际上看起来像是身份配置的用例，而不是访问管理的用例。
标准 SAML 2.0 用例侧重于声明身份的一方（身份提供商）和依赖这些声明的另一方（或多方）（服务提供商）。断言携带所谓的名称标识符，其使用由身份提供者和服务提供者提前商定。
这些名称标识符几乎可以是任何东西，但它们大致分为两类：瞬态和持久。临时名称标识符仅在当前会话的上下文中有用（本质上仅表示“我知道这个人是谁”），并且往往用于保护主体的身份，同时允许某种类型的特权访问。持久标识符可以是不透明的（与使用 OpenID 访问 SO 的方式类似），其中断言方可以重复验证主体的身份而无需公开其身份，同时在断言方和依赖方之间维护动态但稳定的共享标识符，或者更重要的是，例如 Active Directory UPN（可以提前预先商定）。
当谈到密码时，正如您在问题中提到的那样，服务提供商（依赖方）永远不会看到用户的密码。服务提供商将用户通过身份验证请求移交给身份提供商。身份提供者将用户连同响应发送回服务提供者，在身份验证成功的情况下，该响应包含关于在身份提供者和服务提供者之间的关系的上下文中的用户身份的断言。
就您的问题而言，最重要的是 SAML 2.0 没有提供创建本地“应用程序”用户帐户或将该本地用户帐户链接到联合身份的方法。这根本不是 SAML 2.0 试图解决的问题。
现在，回到您的业务规则......
在我看来，您想要做的是帐户链接或注册 - 我会这样处理：
- 用户访问应用程序，单击按钮以使用身份提供商的身份
- 应用程序生成身份验证请求并将用户定向到身份提供者，并携带该身份验证请求
- 身份提供者要么登录用户，要么重用现有的身份会话（如果用户有身份会话）。 IdP 生成一条响应消息，其中包含有关用户的断言。在您的情况下，此断言至少应带有持久名称标识符。身份提供者将用户引导回应用程序，并携带响应消息。
- 应用程序处理响应消息。如果传递的持久标识符存在映射条目，则可以从该映射中识别用户并以该本地应用程序用户身份登录。如果不存在映射条目，则可以要求用户本地登录，并且在成功本地登录后可以生成映射条目，或者可以自动创建用户帐户，并且可以要求用户输入附加信息（姓名、电子邮件地址）等）“公司”用例是不允许自动帐户链接或创建，并且映射必须提前存在。
至于消息的内容……
The OASIS安全服务技术委员会 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security有一个 zip 文件下载，其中包含 XML 模式各部分的大量文档，包括示例。协议和配置文件文档也非常值得阅读，因为它们描述了身份对话中涉及的各方之间的消息流。
我发现有大量的演示文稿非常有用。具体来说，SAML v2.0 基础知识 http://www.oasis-open.org/committees/download.php/12958/SAMLV2.0-basics.pdf作者：Eve Maler 帮助我开始意识到 SAML v2.0 试图解决什么问题。本演示文稿包含断言的示例。有更新的演示文稿和指向其他资源的链接saml.xml.org http://saml.xml.org/wiki/saml-introduction.
我不确定这是否有帮助，因为您的用例似乎不是 SAML 2.0 想要做的事情。您可以根据需要向请求和响应添加属性和扩展，但我看不到许多身份提供者对这些属性和响应执行任何操作。
