如何成为 SAML 服务提供商

我的公司目前正在开发一个 JavaWeb 应用程序。我们的一些客户机有内部 SAML 服务器(身份提供程序?)并要求我们融入他们。所以最近我一直在阅读它,并玩弄 OpenAM。经过大约3天的这个,我有一个大致的了解,但仍然有一些差距,我的知识。我希望有人能帮我解释清楚。

下面是我对用户登录的工作流的想象。

让我们将我们的客户 SAML 服务器定义为 https://their.samlserver.com。所以用户来到我们的 Web 应用程序寻找受保护的资源。假设 URL 是 http://my.app.com/something

所以如果我是正确的,My.app.com就是 SAML 定义的 服务供应商。我们的应用程序认识到这个用户需要登录。然后我们向用户展示这样的页面..。

<script>JQuery Script to auto submit this form on ready</script>
<form method="post" action="https://their.samlserver.com/Post/Servlet">
<input type="hidden" name="SAMLRequest" value="someBase64Data" />
<input type="submit" value="Submit" />
</form>

someBase64Data应该是 base64编码的版本..。

<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0">
<saml:Issuer>http://my.app.com</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

因此,我的第一对夫妇的问题

身份证值应该是多少?

为什么我可以声明自己是 发行人

身份提供商知道我吗?也许这就是我在 OpenAM上看到的 信任圈。如果它真的知道我,它是怎么知道我的,它需要知道什么?

因此,在用户被转发该页面之后,他们将被带到 IDPhttps://their.samlserver.com提供的页面。他们在那个页面上进行身份验证,而 IDP 会神奇地验证身份验证并查找用户。身份验证成功后,IDP 发回一个定义为 <samlp:Response>给你

还有几个问题

首先,<samlp:Response>如何返回到我的 Web 应用程序,以便我可以检查它?

我应该在这个回答中寻找什么来验证它是成功的呢?失败是什么样子的?

我们目前使用电子邮件地址(LDAP)来识别用户,因此我们可能会从响应中获取这个地址,并以与现在相同的方式使用它。还有什么我需要注意的吗?

现在我们已经检查了响应的有效性,我们可以像当前一样给用户一个会话。但是当他们想退出的时候,有没有这样的工作流程?我必须通知 IDP 用户已经离开了吗?

最后,在我的阅读中有几个主题被抛出来,我不确定它们如何适应这个工作流程。它们是 信任圈代币艺术品

谢谢大家的帮助。在过去的几天里,我发现了很多信息,也许我可以在多玩一会儿之后把它们拼凑起来。但是我还没有找到一篇直截了当的“ Here’s the Post”工作流文章。也许是因为我搞错了。也许是因为这个没那么受欢迎。但我真的想确保我得到了工作流,这样我就不会错过像用户身份验证这样重要的关键步骤。

43296 次浏览

In response to your specific questions:

1.) What is the "ID" value supposed to be?

  • This should be a unique identifier for the SAML request. The SAML 2.0 specification states that it's really implementation specific how this is done, but makes the following recommendations:

The mechanism by which a SAML system entity ensures that the identifier is unique is left to the implementation. In the case that a random or pseudorandom technique is employed, the probability of two randomly chosen identifiers being identical MUST be less than or equal to 2 ^ -128 and SHOULD be less than or equal to 2 ^-160 in length. This requirement MAY be met by encoding a randomly chosen value between 128 and 160 bits in length.

2.) How does the IdP know about you?

  • Your SP needs to be registered with the IdP. To accomplish this, the SAML specification defines a format for "SAML Metadata" which tells the IdP where your SAML receivers are, what your certificates are, attributes you exchange, etc. OpenAM likely dictates some minimum requirements for configuring a trusted SP. This varies in each product.

3.) Where's the Response go, and what to check?

  • The Response will go to your Assertion Consumer Service (ACS) URL usually defined in the SAML Metadata you exchange from your SP with the IdP for initial setup. When you receive a SAML Response, you need to check many things - but most importantly, the SAML Status code should be "success", the inResponseTo ID's should match the request's sent ones and you must validate the digital signature on the Assertion. For that, you'll need to trust the IdP's public verification certificate, and you'll probably also want to do revocation checking.

4.) What about Logout?

  • SAML 2.0 also defines a profile for Single LogOut (SLO). This will not only log you out of the SP, but also the IdP and potentially any other SP's you've established a session with. It has a similar request/response flow as Single Sign-On (SSO), and thus similar things to set up and check (status codes, signatures, etc.).

So in short - this can be quite complex to implement from scratch. It's best to use tried & true libraries and/or products like Ian suggests. Companies like his have invested hundreds of hours of developer time to implement according to the spec and test interoperability with other vendors.

If you're just trying to set a single Java application up as a Service Provider, you should consider using a Fedlet from either Oracle (as a standalone ) or ForgeRock ( bundled with OpenAM ). The ForgeRock Fedlet has some issues interacting with Shibboleth 2.2.1 as an Identity Provider, but I find it to be somewhat simpler to configure and more informative.

Each has explicit instructions contained in the README to help you deploy. Once the Fedlet is configured and communicating with the IDP, the success page shows you all the code you need to integrate federated SSO into your application. It does the background work of sending and receiving AuthnRequests and Responses.

Scott's answer responds quite well to the questions you had, but I think that trying to write code on your own that generates the SAML is reinventing the wheel. The Fedlet was designed with precisely this use case in mind.