I have written a Service Provider and testing the same with some IDPs. When I tested with ADFS, login works fine but have a problem during logout. When I set a logout request, I am getting a valid logout response from the ADFS but when I send a new AuthNRequest after successful logout, ADFS is not asking for any credentials and making the user previous logged-in as the current user and sending a valid Auth Response with the same. Here is the LOGOUT RESPONSE sent by ADFS :
<samlp:LogoutResponse ID="_4b1507e9-85c6-4aab-8a20-9bf420f15057" Version="2.0" IssueInstant="2018-01-24T10:16:46.793Z" Destination="https://manoj-3374:9876/mc/SamlLogoutResponseServlet" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="ME_7d8bc526-b585-460e-a677-cab2c9f4c43b" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://hostname/adfs/services/trust</Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ds:Reference URI="#_4b1507e9-85c6-4aab-8a20-9bf420f15057"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ds:DigestValue>pLbKQReWhLBgYkDMe4ets84pnQq21NexmofA/49bBXQ=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>oq60dpAGnAUdjmLFUFZDIcc/LZo5dhxVgc12nMUdAmffl3CgMXXOUvdprUaAWkf84gTZ2zaHb0iIHDRIjjicrfR1NunmgT9/dpP0rHvDJ5ViCyb6Lf7eWomyDqAAvpWGL9MwHIpW0tQZj04DxYbMzRJrwyvCClKO8IQ+xin09wSXcU5Ibm7l/75FZB/ZNI35e/PietCL6Rt8uf/YjH4sYthIYzTBn70iYAElO87YFvVBP0RtK0vv5WpcvnxaGh0eWDnYAYJHEIZQ/EjZFCEVfuneqL2F9n3uXQR9FW2N9Kb3mdKy74PSh/Qbsosq3efZ7sC5DXUcVseJIrJTynpBrw==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC/jCCAeagAwIBAgIQMQknUWY/VZtEgNVEh0GpgjANBgkqhkiG9w0BAQsFADA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBzZHBvZC1rMTJyMi0xLmNzZXouem9ob2NvcnBpbi5jb20wHhcNMTcwNzExMTMwNjAwWhcNMTgwNzExMTMwNjAwWjA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBzZHBvZC1rMTJyMi0xLmNzZXouem9ob2NvcnBpbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8DceRgiArTb0H5EgBA35fjOKFz5yP/t76u2bWJCnaNw7qwUjssy/vt4XH7H8nJ3O0nMSkaTAQZJp4LTHIe3fqnKNzqWsJFtYoG/d7YW22O7rOGfgtDQdcZXbvFZYc41tP77vQ4i/FsEm9t/QZAQdqGkzMQtF1JymvdfJ/e4Ui+JCmHwyDkzkgPmdPjJM3Rz1KwJxgW3fAFaORBnaXySIW0D6bwZgSO3JMohSGtOk3hJ4+ykW/A5dwhBeSL00+6n/KjrCCRavoZX6oATLpj+000mhhFmjibo/jOh24rtRqz7r9h0LHpWXzSiApFxTEiH2SsBsfKXFEzvgRjj/0LftFAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJCuMIcGs8tTVPqiYwU7G1ZSyBQ2jbL58Qml+O2zrvCWtlBrkRnybvOd9SQPKSD4xklwJA2dkFk0tUrziyw8C23yuwUusMpnvHQnrLTumzcxwUpM8wPJvnkCcwPf2ECjRkSVHJyFr7vODn7tusVL0yVjLeGqUk8QdvFdwj1TV7wLTNSanQlKlPQarVdN+k6q8GVWVxcv1ljbpDrGnBK6aE+91ypuwz/NQOIyI/qCwMZaEi2bbxbWRHe2en4IkuE6KSOq/nDbqQsXOYjRjOjXGz2nxgJxIu9/Jv391RsSF7OooMJ0SByO53BkDix+LZnu5WvyzrCyYhxODwomy/jTSy4=</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status></samlp:LogoutResponse>
How did the user login? Were they a domain user and they used Windows integrated authentication?
If so, the logout response will indicate success even though the user wasn't logged out from Windows.
If they used forms authentication then they should have been logged out.
In that case, you should check the ADFS Windows event log for more details.
Related
I am new to KeyCloak, and am trying to configure it as a SAML IDP to a SalesForce client.
IDP initiated SSO flow works fine. I am directed to the Salesforce home page correctly post-authentication. However, SP initiated SSO gives me a JSON output instead of the Keycloak login page.
This is the URL that SalesForce is redirecting to (masked IP):
http://10.99.xxx.xxx:8080/auth/realms/test?SAMLRequest=...
SAML tracer indicates a valid SAML authentication request.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://f-corpcont--dev.my.salesforce.com?so=00D3K000000lOS"
Destination="http://10.99.xxx.xxx:8080/auth/realms/test"
ID="_2CAAAAXJxZQlkME8wswMDAwMDAwMDA2AAAA3kJle3T1o4lEOE9QztKYIVXwLjlHOcfEaw-7mLWvYqmEiPv5SS32lT0WcQIbjXTP-qO779xPjACwqlhiGs9ZM8ZmltHZd6stzimY1Br3b1_5PqBgWxExV7R1FAAxZ914_3s8rViWWGxmKKGFN94OG2WBh3SMPF3WwGagDIZLRKtSpcGIDCGkuYERb_DR0LgOflx-C0kF7XqKdtU8OTTbk0HpoCKQ8oRh58Mai1eFlqgKf50rdGsFQmCQa-Sg0-JyZg"
IssueInstant="2020-05-04T19:39:22.807Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://f-corpcont--dev.my.salesforce.com</saml:Issuer>
</samlp:AuthnRequest>
The JSON output I see in my browser is:
{
"realm": "test",
"public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqHobhU5mQ2itvVfkDWm64sLgT9dfoCNm137ul+A7YRNSXk5g0JEGxoZLVdicRQUx0mr4z6BEM+LN/mztSsigG0aQIqUY8y1un33kBk5gE6W3jaFDX6Rsap/lcXIoO7Jl/pzjAxf3R8RyMMhFQ4Hi1rHl2wSXMWfeNLaoLrzy+LEG1KNZpfhbfG1HUa5fEYpI0sSWEEgcP3faEy2JWOJrfJrcS1tezDD+7x4u+fTUJt0M8vsIjMDAX9UUu+JXnG901a15drj9UjYJyiMJTFQt3Rdrxv96XZa93fKyB36an5GDZWPiwEehtjAJ4mQ0oo0v/TmevoJwZd7YTvClQIDAQAB",
"token-service": "http://10.99.xxx.xxx:8080/auth/realms/test/protocol/openid-connect",
"account-service": "http://10.99.xxx.xxx:8080/auth/realms/test/account",
"tokens-not-before": 0
}
Any pointers would be appreciated
You have used wrong URL for SAML request. Wrong:
http://10.99.xxx.xxx:8080/auth/realms/test?SAMLRequest=
Correct:
http://10.99.xxx.xxx:8080/auth/realms/test/protocol/saml?SAMLRequest=
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?
When user clicks login, redirected to Keycloak login page & then after successful login, user comes back to application with 400 error page.
Server log shows following:
[Server:node-00] 13:40:00,709 WARN
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-30)
state parameter invalid
My application conf is:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<secure-deployment name="appWEB.war">
<realm>demo</realm>
<resource>app</resource>
<public-client>true</public-client>
<auth-server-url>http://localhost:8180/auth</auth-server-url>
<ssl-required>EXTERNAL</ssl-required>
</secure-deployment>
</subsystem>
Application URL is https://localhost:8443/app & redirect_url is https://localhost:8443/app/private.jsf.
When I use http, it works. But the error comes when I use same with https.
Any thoughts?
Here it can be many scenario which may failing with https
Keycloak running in https
Create self sign certification for keycloak.
Import this certificate to your local Java environment.SO handshake can be possible.
I hope you generate the certificates in keycloak you can find the the certificate inside keycloak/security/ssl.
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>
Building off of #Scott T.'s answer:
...PingFederate (acting as an IdP) knows which SPs you have
federated with in a given session. When the user kicks off SLO (from
the example you gave - at the IdP - it could also be initiated from an
SP) the users browser (assuming a Redirect or POST binding) is sent to
each SP with a SAML LogoutRequest.
When I request https://[PingFederateInstance]/idp/startSLO.ping?PartnerSpId=[PartnerSpId], according to server.log, PingFederate issues only one LogoutRequest.
<samlp:LogoutRequest Destination="https://[PingFederateServerInstance]:[PortNumber]/sp/SLO.saml2" NotOnOrAfter="2011-11-22T23:02:37.812Z" IssueInstant="2011-11-22T22:57:37.812Z" ID="NEDH4Khn4TvWsOwfAZxK_XiEc6f" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>XXX:IDP</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#NEDH4Khn4TvWsOwfAZxK_XiEc6f">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>Hnec0X3qfYlE2Z9+ooujtD1HKQk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>L6wmw7RF82s8W2s4YSkwHpnQFo6tFRKUZ3pyK7JEl/7CZyJsxJ5lnfpdaaogm/Gl3S3Y7WoSjbp4
ssaNjtQ3x/nHsYI0zill66yhQ/DNaXAdRuKw6jDi9vqXemkYGx9cNxLkLvc14CUdn9qRA0gZcjyj
ncaZvvWL5Kzy9JOuWSg=</ds:SignatureValue>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">10072824</saml:NameID>
<samlp:SessionIndex>dWh6bd58GRgnbLgeYsTWSVXT7pO</samlp:SessionIndex>
</samlp:LogoutRequest>
My Question:
If I've federated with more than one SP, how should I configure PingFederate so that it issues one request per federated SP?
I'm inclined to believe that:
I need to configure something on this screen.
In agreement with the idea that the multiple SP logout requests are "chained together", the last endpoint URL should be /idp/SLO.saml2.
Let me revise that first answer:
PingFederate knows which SPs you have federated with in a given session.
Should be:
PingFederate acting as the IdP knows which SPs a user has signed into in a given session.
The configuration at PingFederate acting as the IdP would include SLO protocol configuration for each SP connection you have. The screenshot you linked to in (1.) is actually an IdP connection screen, that would be done at PingFederate playing the SP role (maybe that's what you're acting as - it wasn't clear to me in your original query, so I assumed IdP from the nature of your question). You will want to ensure you have configured each SP connection with appropriate SLO endpoints following these instructions. If PingFederate is the IdP it will know to redirect to all SP's that support SLO (and where the user has a session) when a user initiates SLO.
WRT to (2.): If users start the SLO process at the IdP, then yes - users will be redirected back to /idp/SLO.saml2 as the last step. In fact, each SP that you redirect to for logout, will redirect back to the IdP to logout of the next SP. If you start the SLO process from an SP, then the last place users will end up is at that SP's SLO endpoint.