声明未传递给 ADFS 2.0 中的依赖方
好的，我对索赔感知应用程序的整个世界都很陌生。我能够使用 Azure ACS 快速启动并运行，但当尝试使用 ADFS 2.0 作为身份提供程序时，情况有点不同（我想实际将其用作联合提供程序，但目前我我只是想运行一个示例，使用它作为身份提供者）。
我一直在查看 此处的指南，并尝试遵循其中列出的AD FS 2.0 Federation with a WIF Application Step-by-Step Guide指南。它引导您完成 ADFS 2.0 的设置以及一些声明感知示例应用程序，您可以使用该应用程序来查看正在发送的声明。
这样我就可以通过指南中定义的声明（只是 Windows 帐户名）来启动并运行它。问题是当我尝试添加更多内容时。我可以转到 ADFS GUI 中的依赖方应用程序，并使用传递或过滤传入声明规则模板添加颁发转换规则。但是，当我运行我的应用程序时，除非添加的声明类型是名称，否则它不会将声明传递到我的应用程序。
我想要传递的信息之一是登录应用程序的用户的电子邮件地址。因此，我添加了一条规则来传递电子邮件地址，然后更新了示例应用程序的 web.config，以取消 claimTypeRequired 部分下的这一行的注释：
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
请注意，我将其设置为非可选。我还更新了应用程序的联合元数据以添加以下内容：
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
然后，我进入 ADFS GUI，转到依赖方信任并选择从联合元数据更新我的示例应用程序。因此，它现在将该电子邮件列为已接受的声明之一。
然后，我进入声明提供商信任，并将电子邮件声明规则添加到 Active Directory 提供商信任的接受转换规则中（唯一列出的一个）。
然而，当我运行该应用程序时，它没有通过电子邮件声明（或我尝试的任何其他声明）。有人可以告诉我我在这里缺少什么吗？
我还应该注意，我运行了一个测试，将我的应用程序更改为仅接受电子邮件声明规则，它不仅没有通过电子邮件，而且仍然通过Windows 帐户Name 和 Name 声明，尽管事实上我什至没有将它们列为我的应用程序接受的声明。
如果有人能指出我在这里犯了严重错误的地方，我将不胜感激。
按照之前的博客文章启用日志记录后，以下是日志中的相关条目： 
事件 ID 1000，“详细信息中包含调用主体的输入声明”： 
所以您可以看到，我请求的信息显然丢失了。我将日志输出设置为详细，但实际上没有任何其他兴趣。您将看到 NETWORK SERVICE 用户的跟踪记录（具有相同的声明集），但没有什么引人注目的。所有日志条目都是信息性的，没有任何错误。
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用 ADFS 作为身份提供商并希望它发出电子邮件声明，则必须使用发送 LDAP 属性作为声明或自定义声明规则来访问 AD 作为属性存储并发出电子邮件声明。假设用户已经在某处进行了身份验证，则对传入的声明使用传递。在 Windows 身份验证的情况下，Windows 帐户名是从 Kerberos 令牌颁发的，这就是为什么您必须传递它，但您必须颁发其他令牌。
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Active Directory 是否会发出电子邮件地址声明？我不知道如何检查这一点，但如果没有，那么您传递它们就无关紧要了。在这种情况下，您需要尝试“发送 LDAP 属性作为声明”规则；根据我在 ADFS 实例中看到的内容，尝试将“电子邮件地址”属性映射到“电子邮件地址”声明。
在与您类似的情况下，我必须做类似的事情才能让 UPN 索赔成功。我不确定 LDAP 属性可能是复数是否重要。
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.