Question

我在我的asp.net应用程序的SAML身份验证中使用Shibboleth作为SP。 Idp对用户进行身份验证，并将响应发送到shibboleth，后者为从Idp返回的每个属性设置http请求变量。

下面的日志显示了两个身份验证请求。第一个我可以看到正确发送的属性，但第二个没有发送的属性。这些属性通常在xml响应中发送来自idp中的＆＃34; saml：AttributeStatement＆＃34;节点，但这不会出现在第二个请求中。下面的警告日志也显示了这一点。

为什么第二次请求时不会从Idp发送这些属性？

我还可以在config / logs中查找其他内容吗？

我还没有能够一致地重现这个问题。我试图等到Shibboleth删除了它的缓存响应后（我认为它缓存了来自idp的响应？），但有时Idp会返回属性节点，有时不会。

Warn log:
2014-07-29 09:37:11 WARN Shibboleth.AttributeResolver.Query [32]: no SAML 2 AttributeAuthority role found in metadata

Shibd Log:
2014-07-29 09:29:39 INFO Shibboleth.SessionCache [32]: new session created: ID (_4a08732fafc683618ec84f743679a558) IdP (https://<idp url>) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (<client ip>)
2014-07-29 09:37:10 INFO Shibboleth.SessionCache [32]: removed session (_4a08732fafc683618ec84f743679a558)
2014-07-29 09:37:11 WARN Shibboleth.AttributeResolver.Query [32]: no SAML 2 AttributeAuthority role found in metadata
2014-07-29 09:37:11 INFO Shibboleth.SessionCache [32]: new session created: ID (_ebfc98924b1bafc96a646a9e0ef97cd8) IdP (https://<idp url>) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (10.60.112.1)
2014-07-29 09:37:12 INFO XMLTooling.StorageService : purged 8 expired record(s) from storage

Transaction Log:
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]: New session (ID: _4a08732fafc683618ec84f743679a558) with (applicationId: default) for principal from (IdP: https://<idp url>) at (ClientAddress: <client ip>) with (NameIdentifier: test@testdomain.com) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: id-eyHUtkCazAdXC6cMPibbv8YhuYc-)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]: Cached the following attributes with session (ID: _4a08732fafc683618ec84f743679a558) for (applicationId: default) {
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   username (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   userGUID (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   lastname (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   role (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   firstname (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   companyName (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   companyGUID (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]:   emailAddress (1 values)
2014-07-29 09:29:39 INFO Shibboleth-TRANSACTION [32]: }
2014-07-29 09:37:11 INFO Shibboleth-TRANSACTION [32]: New session (ID: _ebfc98924b1bafc96a646a9e0ef97cd8) with (applicationId: default) for principal from (IdP: https://<idp url>) at (ClientAddress: <client ip>) with (NameIdentifier: test@testdomain.com) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: id-jAnsCQo6-BH2skcHhzj8i63jKxQ-)
2014-07-29 09:37:11 INFO Shibboleth-TRANSACTION [32]: Cached the following attributes with session (ID: _ebfc98924b1bafc96a646a9e0ef97cd8) for (applicationId: default) {
2014-07-29 09:37:11 INFO Shibboleth-TRANSACTION [32]:   emailAddress (1 values)
2014-07-29 09:37:11 INFO Shibboleth-TRANSACTION [32]: }

Answer 1

如果您从某种远程系统（OpenLDAP，...）获取用户属性，请尝试检查您的网络连接。不可再现性可能是网络问题或远程系统停机时间的指示（例如重启）。

请注意，Shibboleth使用连接池来检索用户属性，因此在处理请求之前，连接已经被破坏。

关于AttributeResolver.Query警告，您是否可以确定SP上的IdP元数据是否可用？两次登录尝试都使用相同的IdP和SP吗？用户是否一样？

Shibboleth在到期后没有设置属性

1 个答案: