I'm trying to SSO to Share Point 2013 website usin WSO2 Identity Server passive sts support.
Following is the SAML response form Identity Server
<Attribute AttributeName="Email"
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
>
<AttributeValue>admin#wso2.com</AttributeValue>
</Attribute>
I am getting following log in Share Point side.
04/16/2015 11:40:13.61 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication ajau6 Verbose SPSecurityTokenServiceManager!GetProviderByName: Returning Trusted Login Provider for input WSO2PassiveSTS1 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
04/16/2015 11:40:13.63 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication eu2n Monitorable Trusted login provider 'WSO2PassiveSTS1' is not sending configured input identity claim type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'. 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
04/16/2015 11:40:13.65 w3wp.exe (0x0B18) 0x0640 SharePoint Foundation Claims Authentication fo1t Monitorable STS Call: Failed to issue new security token. Exception: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm. at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo.ValidateTrustedLoginRequest(SPRequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.GetTokenLifetime(Lifetime requestLifetime) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) 6130fd9c-aa57-b0ac-0000-0c3c2aa42924
Follows is my IDP configuration in Sharepoint.
$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$realm="http://win-3oo8vau2hv9:48077/_trust"
$ap=New-SPTrustedIdentityTokenIssuer -Name "WSO2PassiveSTS1" -Description "WSO2 Identity Server1" –Realm $realm -ClaimsMappings $map1 -ImportTrustCertificate $cert -SignInUrl "https://localhost:9443/passivests" -IdentifierClaim $map1.InputClaimType
Incomming claim type should be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
NOT http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
SAML Token should have a expiry time longer than 10 minutes.
SharePoint uses saml token validity period to determine the lifetime and if the LogonTokenCacheExpirationWindow (which is a setting in SharePoint 10 minutes default) is larger than the lifetime of the assertion, then SharePoint will not allow a user to logon and will redirect back to the IdP, which will redirect back to SharePoint in an endless loop.
Attribute in the SAML response should look like follows
<Attribute AttributeName="email"
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
>
<AttributeValue>admin#wso2.com</AttributeValue>
</Attribute>
Related
I am using the wso2 sample apps (saml2-web-app-pickup-dispatch and saml2-web-app-pickup-manager) to test single sign on through WSO2 identity server version 5.10.0
The deployment is fine and on clicking the application's login, it redirects to the WSO2 login page successfully.
User logs in successfully but receives error below.
HTTP Status 500 – Internal Server Error
Type Exception Report
Message SAML2 Response Issuer verification failed
Description The server encountered an unexpected condition that prevented it from fulfilling the request.
Exception
org.wso2.carbon.identity.sso.agent.exception.SSOAgentException: SAML2 Response Issuer verification failed
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:569)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processSSOResponse(SAML2SSOManager.java:525)
org.wso2.carbon.identity.sso.agent.saml.SAML2SSOManager.processResponse(SAML2SSOManager.java:358)
org.wso2.carbon.identity.sso.agent.SAML2SSOAgentFilter.doFilter(SAML2SSOAgentFilter.java:98)
Note The full stack trace of the root cause is available in the server logs.
Apache Tomcat/8.5.53
Logs from the server
TID: [-1234] [2020-04-25 19:16:55,881] [7e977cfd-8304-44ba-ab4f-4644baff988e] INFO {AUDIT_LOG} -
Initiator : wickrema | Action : Login | Target : ApplicationAuthenticationFramework |
Data : {
"ContextIdentifier" : "51f93b05-68cf-4bf4-b62b-51e3e2502889",
"AuthenticatedUser" : "wickrema",
"AuthenticatedUserTenantDomain" : "carbon.super",
"ServiceProviderName" : "saml2-web-app-pickup-dispatch",
"RequestType" : "samlsso",
"RelyingParty" : "saml2-web-app-pickup-dispatch.com",
"AuthenticatedIdPs" : "eyJ0eXAiOiJKV1QiLCAiYWxnIjoibm9uZSJ9.eyJpc3MiOiJ3c28yIiwiZXhwIjoxNTg3ODMxNDE1ODA0MzAwMCwiaWF0IjoxNTg3ODMxNDE1ODA0LCJpZHBzIjpbeyJpZHAiOiJMT0NBTCIsImF1dGhlbnRpY2F0b3IiOiJCYXNpY0F1dGhlbnRpY2F0b3IifV19."
} | Result : Success
Your Service Provider application(Pickup-Dispatch) is trying to verify if the received SAML response is issued by the expected SAML Identity Provider. WSO2 includes its ID in the SAML response's <saml:Issuer> tag.
Your application has a pre-configured entity ID for WSO2 in the saml2-web-app-pickup-dispatch.com/WEB-INF/classes/sso.properties file as below.
SAML2.IdPEntityId=localhost
Likewise, WSO2 IS populates its SAML response's issuer with the value you've configured in the Resident Identity Provider's Home Realm Identifier.
But you can override the Home realm identifier with the IdP Entity ID Alias of your Service Provider SAML configurations as below.
Bottom line, the Issuer ID of the SAML response should be the same as what you've configured in the Application as the IdP Entity ID.
Change either value to make them the same.
Code for your reference
This question is in the area of SAML based IDP initiated SSO. As a POC, I have two keycloak instances, say keycloak1 and keycloak2. I would want to achieve the below :
Authentication would be done at keycloak1
keycloak1 then directs to keycloak2 to access an keycloak2 client application.
To do so,
a) create a saml client at keycloak1 under realm1. With IdP initiated SSO Name set as some name without spaces) --> say, keycloakclientsaml. In the Fine Grain SAML Endpoint Configuration section, for Assertion Consumer Service POST Binding URL --> http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloakclientsaml
( https://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated-login)
b) click on above created saml client --> installation --> Export SAML Metadata IDPSSODescriptor and save as saml-metadata.xml ( say ).
c) Add a user in keycloak1, say user1/user#123
d) At the keycloak2, create a IDP ( identity providers tab). Import the above exported saml-metadata.xml and save.
e) In the browser hit, http://<keycloak1>/auth/realms/realm1/protocol/saml/clients/keycloakclientsaml
Prompt for username/pwd, give credentials for user1
f) URL in the browser now changes to
http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloakclientsaml
At keycloak2 instance, I get the error as :
09:20:46,775 INFO [org.keycloak.saml.validators.ConditionsValidator] (default task-6) Assertion ID_789213dd-24f9-425f-ae20-bcadef173bc6 is not addressed to this SP.
09:20:46,775 ERROR [org.keycloak.broker.saml.SAMLEndpoint] (default task-6) Assertion expired.
09:20:46,775 WARN [org.keycloak.events] (default task-6) type=IDENTITY_PROVIDER_RESPONSE_ERROR, realmId=realm2, clientId=null, userId=null, ipAddress=keycloak2, error=invalid_saml_response
Could someone help here.
Are the above given steps correct and complete.
What am I missing
If any other information is required, let me know. would be happy to provide.
Finally got it working.
So here is the answer to the above :
The error pasted above was related to Assertion expired. In my case, it was because of the clientid given in saml client of Keycloak1 was not recognized url of keycloak2. it should be pointing to the keycloak2 realm ( for example, http://<keycloak2:port>/realms/realm2
Then the condition section in the SAML response is VALIDATED at the keycloak2 broker idp.
(code : SAMLEndpoint.java --> handleLoginResponse method)
Leaving this thread here and for clarity the steps are given below in detail:
a) create a saml client at keycloak1 under realm1. With IdP initiated SSO Name set as some name without spaces) --> say, sso.
b) In the Fine Grain SAML Endpoint Configuration section of the above client, for Assertion Consumer Service (ASC) POST Binding URL --> http://<keycloak2:port>/auth/realms/realm2/broker/saml/endpoint/clients/keycloak2samlclient
( https://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated-login)
b) click on above created saml client --> installation --> Export SAML Metadata IDPSSODescriptor and save as saml-metadata.xml ( say ).
c) Add a user in keycloak1, say user1/user#123
d) At the keycloak2, create a IDP ( identity providers tab with name saml (refer ASC url). Import the above exported saml-metadata.xml and save.
e) At the keycloak2, create a saml client and in the IP initiated SSO url give name as keycloak2clientsaml
f) In the browser hit, http://<keycloak1>/auth/realms/realm1/protocol/saml/clients/sso
Prompt for username/pwd, give credentials for user1
I'm using the sustainsys saml2 owin package, and I'm having problems with SP-initiated SLO. I'm new to the saml process, so there's a good chance I'm doing something wrong.
Our signout workflow is as follows:
User hits myapp.com/signout
myapp redirects to myapp.com/saml2/logout
The owin package generates a saml request and sends it to the Idp's slo route
The Idp responds with a successful saml response to the same url: myapp.com/saml2/logout
At this point, the owin package is generating another saml request to sign the user out of the idp. It would get stuck in an infinite redirect, if the Idp didn't halt the process.
Here's a snapshot of my network panel in chrome:
I'm using https://github.com/mcguinness/saml-idp as a development Idp, and here's a stub of my owin configuration:
I suspect I've misconfigured something or I'm using the saml2/logout route inappropriately, but I also find it odd that the owin package would generate another request when it gets a successful response.
Update 11.9.2018
Here's my verbose log starting from the logout process:
Expanded Saml2Url
AssertionConsumerServiceUrl: http://locala.foliotek.com/saml2/linuxdev/Acs
SignInUrl: http://locala.foliotek.com/saml2/linuxdev/SignIn
LogoutUrl: http://locala.foliotek.com/saml2/linuxdev/Logout
ApplicationUrl: http://locala.foliotek.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: True
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl: http://myidentityprovider.com/saml/slo
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false): False
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/linuxdev/Acs
SignInUrl: http://myserviceprovider.com/saml2/linuxdev/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/linuxdev/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: True
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl: http://myidentityprovider.com/saml/slo
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false): False
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/samltestid/Acs
SignInUrl: http://myserviceprovider.com/saml2/samltestid/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/samltestid/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Initiating logout, checking requirements for federated logout
Issuer of LogoutNameIdentifier claim (should be Idp entity id): http://myidentityprovider.com
Issuer is a known Idp: False
Session index claim (should have a value): http://Sustainsys.se/Saml2/SessionIndex: 1926000282
Idp has SingleLogoutServiceUrl:
There is a signingCertificate in SPOptions: True
Idp configured to DisableOutboundLogoutRequests (should be false):
=================
Expanded Saml2Url
AssertionConsumerServiceUrl: http://myserviceprovider.com/saml2/linuxdev/Acs
SignInUrl: http://myserviceprovider.com/saml2/linuxdev/SignIn
LogoutUrl: http://myserviceprovider.com/saml2/linuxdev/Logout
ApplicationUrl: http://myserviceprovider.com/
=================
Http POST binding extracted message
<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_d02d42fbb8ed00bbee02" InResponseTo="idf75b17a7713e4f698f891edf1fcca117" Version="2.0" IssueInstant="2018-11-09T16:44:01Z" Destination="http://myserviceprovider.com/saml2/linuxdev/logout"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://myidentityprovider.com</saml:Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><Reference URI="#_d02d42fbb8ed00bbee02"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><DigestValue>X+93fiv6vuuy8sIhmFFxIVxNgAy/f1Zk62RRh/rn91I=</DigestValue></Reference></SignedInfo><SignatureValue>qXMlLe2fciQR6u7Ddx40RFI51IJ5r8A3m7X7mrgIMHBdFf2vypiCFxqOrEOKCSIqWzDUxVXujWyMQzO/zZtVyZlm6xXnb3lId0VDHLEIUT/8kyNsodzvzPIyTMaMMV/cmhQ3UZlYRv9BeyPswpkosFTn/xc6c+BX9z+w4AN4KDMFfYlTeu/uyDBa1u5zr/Ze6OXwP7///Mo/zdy2ZXyHJhia+yscWZ+Hrb49ekI9csJvuic0p6ttJPjS72tmEesGR1vLT0Y/5T+SqOVmmbmN8hZygRxrEwgfo9oNI+8BBC7aYK2PCtTZZFwoO3KsEEttQjxzKTbzja9s8XslGxfKkw==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIDgzCCAmugAwIBAgIJALOc35pt94LuMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhNaXNzb3VyaTERMA8GA1UEBwwIQ29sdW1iaWExFTATBgNVBAoMDEZvbGlvdGVrIEluYzEMMAoGA1UEAwwDSWRwMB4XDTE4MTEwOTE1MDI0MVoXDTM4MTEwNDE1MDI0MVowWDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pc3NvdXJpMREwDwYDVQQHDAhDb2x1bWJpYTEVMBMGA1UECgwMRm9saW90ZWsgSW5jMQwwCgYDVQQDDANJZHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDhX8PX+C/1orPpFnOIRy7UkrLU7YCq6DNzB5QSUzT366++ZCWFzx+Ub+HFxbR/htY/EAramlCNFawOSGS6mnWev/tiokGObXdMK6tAXyZZMc/u9Rg65EjM892Oep6gIEWgjnE+l7M8v84QOWqAl+GaeM8YZJKHXAZ+7MVMgkMWeYKrksvQdKrQjhyzqoLmBNL5yGBgEH1KEtFy0A0qYdiwdWptvaeWkTk6tp3kfminRaQ1bj/BmMwAWeDbE7EFkk7wF1ig4QhTINoVFQhPGa/+sPg+NuDNlGszDBV3fmfpHwPpjRr4zzoNyJnMvf3u1+C63c7DPSC+uKGvYlgeWbc/AgMBAAGjUDBOMB0GA1UdDgQWBBQvczxcOnaazyGJ8H3vi1vY6g24xDAfBgNVHSMEGDAWgBQvczxcOnaazyGJ8H3vi1vY6g24xDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAoMsoDnrEPCS+VIqVlnlbxxd4lx5AYMvUTZPugJ88+Jjp/1kkKbxWzbJBR1yl0v9quLoQ/u5XkYoSI3u/azydywpADlgsKHrL7Ger+ZU2pdSCK9LTbOP3gnginmPldB7LW6jxWxuEYadWLpYocEFU6Ua7XJUDOzMpO3SXxmhiyhvQC2PF0Q1uehNkwIpUP+9I9ulAXxjScyputgYjkWjiLYu+gcWYW6DmeWqJKyYR6XSwaa+QV4/UPupBmSc1Bx7BuF29+1RwJyTEI6Uz5wQe+lbzZ5ay3J3oa3lilwYg/HYq4mQzVucHEhQLsU9ZIfuGStMHX23sdzWuEBbcQgCCd</X509Certificate></X509Data></KeyInfo></Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status></samlp:LogoutResponse>
=================
Here's my info log from the logout process
Sending logout request to http://myidentityprovider.com
=================
Sending logout request to http://myidentityprovider.com
=================
Federated logout not possible, redirecting to post-logout and clearing local session
=================
Received logout response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id, redirecting to http://myidentityprovider.com/saml/slo?SAMLRequest=fZJdS8MwFIbvB%2FsPJbeyNv3Y1oatOBhCYXrhxAvvYpKu0XzUnlT2803rJpugkJvz8bznPYesgGqVtGRnD7Z3j%2BKjF%2BCCo1YGyHdpjfrOEEtBAjFUCyCOkf3mfkeSEJO2s84yq9Al8z9CAUTnpDUoqLZrJHmRFuw1LnKcUpYt2JImC1rXOc94yuZpnaHgWXTggTXyvKcAelEZcNQ4n8JxPovjGS6e4gXJUjLPX1Cw9WtIQ91INc61JIpqq6R%2Fpj9y8RmOkRPvIbOaLPESR4P3CJRF5XQSBKtxFTIO68qThLKMKnrFjlgSnXVX0RV3ofTgL1Ftgzvbaer%2BPlEcxmNG8lk9thKhqVQbzjsBgErXCN4Py4GWrrlxjdUU3m4PQ9Pg52zge9yFgZbsvYA%2FSGW4OJZxkSwwxkmenIhf9enkJ3%2F1Ocov&RelayState=MnZ2DPYtc9cY8CkEaR5CRJDz&SigAlg=http:%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=LS0QmYpXX2utWqmEKQJmMeQukm%2FFFVUZCP8I0C7sIt1LklVK0NzuqrJgG9VGwO6uPBZObpZ%2FU9%2BZVddCoIGmg3FCKrhhW7hspsQNN%2FGqpf0QY3kxW%2Bt956TqgynW0yM4I9%2Fc7X%2F9Sy4keFu1uxihjemm%2BCNlZdRS71ch4SyG4YStmKZrWJns1T6H4m8d2eBK7O2KVn9iqwIh6OaV5S6obhpMH9gzx5Y01uc5fTm2gfdoExuVNsKbZB8ycois1MEEz7Uox5zRm09gEfCNMHKf2Dp%2Fwd7GmQoK84VvPoNrxl5047WxfKxkhQPTRFbM5h50peFjOlnFN0yKw9C3DARSBw%3D%3D
=================
After digging into the code a little, I've found if I do the following:
GetLogoutResponseState = (req) => { return null; }
...in my Saml2AuthenticationOptions.Notifications, it works as expected.
From here, I still suspect I'm configuring something wrong, or the IDP is sending the wrong data, but I don't know where StoredRequestState is being initialized. It appears that it contains the wrong returnUrl.
Looking at the logs, I think that this is the sequence of events.
SignOut on your application is hit and redirects to the logout endpoint in the Saml2 library.
The logout endpoint is hit and initiates a logout request to the Idp.
The Idp renders a page (that probably contains some kind of SAML response - but might be incorrect).
The logout endpoint is hit again and this is wrong
Either this is a duplicate request.
Or it is a response that doesn't get properly detected by the Sustainsys.Saml2 library
What makes me really confused is that in the second run all the requirements for a federated logout are fulfilled. Specifically it does find the LogoutNameIdentifier. That shouldn't be possible, as the local session cookie is normally cleared when the redirect to the Idp is done.
To understand further what is happening I recommend that you download the Sustainsy.Saml2 source, link directly to the project and set a breakpoint at LogoutCommand.Run. That should help you understand better and be able to further examine the requests.
I tracked my problem down to the LogoutCommand.Run being called twice during the initial GET request to /saml2/logout. Once from the Saml2AuthenticationHandler .ApplyResponseGrantAsync method, and once from the Saml2AuthenticationHandler.InvokeAsync.
The solution was to set Compatibility = new Compatibility { StrictOwinAuthenticationMode = true } in my SPOptions. Which prevents the LogoutCommand from executing within the ApplyResponseGrantAsync method.
I'm a little unclear on the Passive vs Active authentication modes, but my guess is that I'm indicating to the Sustainsys package that I'm controlling the authentication (including signing out) manually. Maybe Anders can clear that up?
Our Java app is federated with customers ADFS 3.0 server.
There is an issue after sending authentication requests (SP initiated) to ADFS server over SAMLP.
It is for intranet use case, where windows authentication was specified on ADFS server in authentication policy.
SP app is using ForgeRock's Fedlet library that is forcibly sending RequestedAuthnContext attribute withing SAML authentication request :
samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact"
>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
We had initially also issue with extranet authentication, where Forms authentication was selected on ADFS. We have solved that with adding Claim custom rule for our RP :
exists([Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "urn:oasis:names:tc:SAML:2.0:ac:classes:Password");
Now we are stacked down with intranet use case.
On ADFS side we got following error :
MSIS7102: Requested Authentication Method is not supported on the STS.
at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Could I add/do something for it ? Is it possible to say in custom rules IF IT IS INTRANET, AUTH METHOD IS WINDOWS or something like that?
You could always try authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified", which should let the IdP choose whatever it can use. As the SP, you don't really know (and should you care?) which methods are available to the IdP...
We have solved this by sending more authentication options and specifying Comparison to minimum
<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="minimum"
>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
In our SSO scenario, we are using ADFS 2.0 as IDP and Shibboleth as SP. It is an SP-initiated sign-on. After configuring, when I try to establish communication between Shibboleth and ADFS 2.0(throw browser redirect), ADFS 2.0 is throwing the below error.
The verification of the SAML message signature failed.
Message issuer: http://sampleserver/adfs/services/trust
Exception details:
MSIS1015: Server required signed SAML AuthenticationRequest but no signature present.
Event id - 320
Related Event id - 364
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolSignatureVerificationException:
> MSIS1015: Server required signed SAML AuthenticationRequest but no
> signature present. at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ValidateSignatureRequirements(SamlMessage
> samlMessage) at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest
> issueRequest) at
> Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message
> requestMessage)
We haven't used any signature yet. I also have made SignedSamlRequest to false in ADFS properties. Signing of SAML at Shibboleth was also disabled.
I could not find any information in Microsoft site - apart from generic guide for this sort of errors.
Please advice on this error.
I was able to find the solution after a lot analysis. This is a Shibboleth configuration issue. In the application defaults section, the entity ID should be unique to the application.
ApplicationDefaults signing="false" entityID="http://URL of the protected Application "
REMOTE_USER="eppn persistent-id targeted-id"
Another variation of this error happens when sigining is set to true. It will result in Signature mismatch error in ADFS.