I configured the logout endpoint (URL) in the relying party trust as:
https:\abstractmachine.domain.local/adfs/ls/?wa=wsignout1.0
With POST binding
I also changed the default SingleLogoutService node value in the federation metadata from its default to the same link as the end point URL configured at ADFS. Without renaming it was giving error while sending the logout request.
Now, after configuration, the ADFS does say it logged out successfully and displays its logout page but users can still login without having to provide creadentials and it seems that the previous creadentails are still being cached.
Also, it is not redirecting to the response URL (I have set the response URL as:)
https:\abstractmachine.domain.local/webapp/logout.aspx
SAML logout not working in ADFS 2.0
I configured the logout endpoint (URL) in the relying party trust as:
https:\abstractmachine.domain.local/adfs/ls/?wa=wsignout1.0
With POST binding
I also changed the default SingleLogoutService node value in the federation metadata from its default to https//abstractmachine.domain.local/adfs/ls/?wa=wsignout1.0. Without renaming it was giving error while sending the logout request.
Now, after configuration, the ADFS does say it logged out successfully and displays its logout page but users can still login without having to provide credentials and it seems that the previous credentials are still being cached.
Am i missing some settings or is there any other method for logging out of ADFS with SAML request?
Also, it is not redirecting to the response URL after logout
The logout request that I am using is as below:
<?xml version="1.0" encoding="UTF-8"?> <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_a8b394ff-a850-484d-91a1-2daeeeb35b52" Version="2.0" IssueInstant="2016-07-04T13:19:02.582Z" Destination="https://nsv-adfsbal.dristi.local/adfs_app/IdPLogOutResponse.aspx" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" NotOnOrAfter="2016-07-04T13:24:02.582Z"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://nsv-adfsbal.dristi.local/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/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_a8b394ff-a850-484d-91a1-2daeeeb35b52">
<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>knf74cRA51WBnpL3ZvPolhWHY90=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>c7VpbqOi0iRaRjfP8EUrS1GS0ne8MA4uW26GA62b5YwHlIHjC91fTfv4r/IuXONs7ny3J8c/If+jKK3dpttesmYmv1kq3p16o5IxlAEwoZKrBDsaWu+JxZ6xZV1dQ2y+vvPL1cCUwa9FobUXwx5SYx29SHJbHhwe81u5fCCwBa2TPj9gbzekJoKy3JeayCzfw8Bl7CPMfM/aDNgNyOpjZ+Lwvm7mk4ejvwbOSFsFBYToVMnWmeZGkwbnyYvuLrywdxxLN1R0JB/St4mbOpki9As4ndIwiNKUF311NM13QNzCAiI3rvf25EyJf2dOujqxtW7UMat5Yju22IgCBOKbxA==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIC7DCCAdSgAwIBAgIQPm2vN8ge2IxCDYSffnDWbjANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBuc3YtYWRmc2JhbC5kcmlzdGkubG9jYWwwHhcNMTUxMTI2MDYxMTQxWhcNMTYxMTI1MDYxMTQxWjAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBuc3YtYWRmc2JhbC5kcmlzdGkubG9jYWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCeezsC3zzG3CqW7fOSEC/qcnwAaK/UFn1OwMlATGujg4d5veYQAxq9U6c1mZ1v6vSzqg2i7a+/3wop7pk8pwHkqOmepM4mxgwrVMA8PqVrYEDDoWXv4EP1YCpEF2WZl2Oc2P0ttLHVIdtk4ItWoMk5Ag65uR1FkMC0DrdA4jeo5YQLo+sEyu8NBiUdKsdNdTXVSOT68dG3P8CG1gTsq8Mr+B0QHH+2e96DopuE59k13DrPw1YNKOk1MISRydYEItRWRHSCZp5RpC7ATf8b95fR9W9OtjC2vPHD1IFJYf8EiUB15ei94AMb5ImAE2DqGh8WGD9MeVUnSFHCX4XNq85ZAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAARUaNFCRal6Mctt4++P2jX77U8lXby7Bk3HmPi8GmTIZyP+dkOL4F/SZ0EC1TGhfaTpQKT3sTRYnCYsQiVzozaQp0eQGs4mlRAqqF6OHnB8ndDYPDE85XSYP4K2FDI/bzP2v2aowGHuZfyONvzgPF5NNtSl7ECo6DPEpSQ15DhTxfkC/YvJteiBhvY+2ij2+2fisl1i8GYzv/E8WnBvF4tJ9rI0EXC4GJ3Az2X+TgJF60Gqf+V2Jqc2KEqLqtG9nLQ1QU5uqS30lsz6m8LrSQkKvUi+RtSlg+rxA+D6hXGMwqfVQbR6yTrYLoyV5Z1zKmS0VXHXellq0Ltmejf6spg=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo> </ds:Signature> <NameID xmlns="urn:oasis:names:tc:SAML:2.0:assertion">user.name#user.local</NameID> <samlp:SessionIndex>_7235ddb0-9fca-4545-9c57-aecdfa4b8eb2</samlp:SessionIndex> </samlp:LogoutRequest>
Related
In the latest WSO2 Api Manager, the default token endpoint seems to have changed to https://localhost:9443/oauth2/token
In the previous versions, the token endpoint was https://localhost:8243/token and invoking this endpoint generates a 404 resource not found error.
Is it possible to enable the previous token endpoint in the latest WSO2 Api Manager or is the oauth2 token endpoint the default to be used?
For all the APIM versions, OAuth2 token endpoint is https://localhost:9443/oauth2/token.
Before APIM 4.0.0 version, we have added a new proxy API to the gateway which will route the requests received to https://localhost:8243/token to the original token endpoint https://localhost:9443/oauth2/token. If you check the <APIM_HOME>/repository/deployment/server/synapse-configs/default/api directory in a APIM version before 4.0.0, you can find several endpoints that are proxied through gateway (_TokenAPI_.xml,_RevokeAPI_.xml etc).
From 4.0.0, we have removed this extra hop(_TokenAPI_.xml) for token call and asked users to directly use the actual token endpoint (https://localhost:9443/oauth2/token).
If you need previous experience in APIM 4.0.0 version, just by adding the _TokenAPI_.xml to the <APIM_HOME>/repository/deployment/server/synapse-configs/default/api directory, you can use https://localhost:8243/token endpoint.
For you reference, I have copied the same XML here.
<api xmlns="http://ws.apache.org/ns/synapse" name="_WSO2AMTokenAPI_" context="/token">
<resource methods="POST" url-mapping="/*" faultSequence="_token_fault_">
<inSequence>
<property name="uri.var.portnum" expression="get-property('keyManager.port')" />
<property name="uri.var.hostname" expression="get-property('keyManager.hostname')" />
<send>
<endpoint>
<http uri-template="https://{uri.var.hostname}:{uri.var.portnum}/oauth2/token">
<timeout>
<duration>60000</duration>
<responseAction>fault</responseAction>
</timeout>
</http>
</endpoint>
</send>
</inSequence>
<outSequence>
<send />
</outSequence>
</resource>
<handlers>
<handler class="org.wso2.carbon.apimgt.gateway.handlers.ext.APIManagerCacheExtensionHandler" />
<handler class="org.wso2.carbon.apimgt.gateway.handlers.common.SynapsePropertiesHandler" />
</handlers>
</api>
Save this to an XML file named _TokenAPI_.xml and add it to the above directory. After this, you can use https://localhost:8243/token to obtain a token.
In versions before API-M 4.0.0, the token endpoint was still https://localhost:9443/oauth2/token. But a proxy (https://localhost:8243/token) was used to invoke this endpoint. You will be able to see this by viewing the _TokenAPI_.xml file in <API-M_HOME>/repository/deployment/server/synapse-configs/default/api directory.
From API-M 4.0.0 onwards, this proxy has been removed and the token endpoint (https://localhost:9443/oauth2/token) is invoked directly.
I'm implementing SAML 2.0 using AspNetSaml library and JumpCloud as IDP in an ASP.NET Web Forms application. Below is my Service Provider metadata that I've configured in JumpCloud:
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
validUntil="2020-04-25T04:40:01Z"
cacheDuration="PT604800S"
entityID="SPEntityID1234567892">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://localhost:44338/SSOLogin.aspx"
index="1" />
</md:SPSSODescriptor>
</md:EntityDescriptor>
The SAML request is being initiated from Login button on the Default page in my ASP.NET Web Forms application.
var samlEndpoint = "<jumpcloud saml app end point>";
var request = new AuthRequest(
"SPEntityID1234567892", //TODO: put your app's "unique ID" here
"https://localhost:44338/SSOLogin.aspx" //TODO: put Assertion Consumer URL (where the provider should redirect users after authenticating)
);
//redirect the user to the SAML provider
Response.Redirect(request.GetRedirectUrl(samlEndpoint));
After I initiate the SAML request, I'm redirected to my IDP and it asks for authentication. But after authentication when I'm redirected back to my application (https://localhost:44338/SSOLogin.aspx), the Forms object is empty.
This makes the Request.Form["SAMLResponse"] object as null.
Can someone please provide some pointers on what I'm doing wrong? Thanks!
I am building an application that authenticates users with SAMLv2. After successful authentication by the Identity Provider, response is returned to browser which is then sent to target server.
Trimmed response looks like follows:
<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="#uuid-73c06e86-88d2-4204-91f4-3d484bc782cc">
<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>H9ffPJ6/jq25p13BcziR0hNLkGg=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>FegjeGwQO..J7hpJEQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate><!-- certificate data --></ds:X509Certificate>
</ds:X509Data>
<!-- more certificates -->
</ds:KeyInfo>
</ds:Signature>
I have sequence of X509 certificates <ds:DigestValue /> and <ds:SignatureValue />. What do those two fields contains and how should I validate whether response is returned by valid server?
The signatures are standard XML signatures. This validation can for example be done in java using OpenSAML. Here is a blogpost showing how.
The "validity" or trust of the IDP is something you have to determine in your pplication. If the signature validates then it means that the SAML message was sent from a the IDP with the corresponding private key. Then you must decide if you trust that IDP.
i recently created a claim aware web app using wif.
This app contains an update panel that loads dynamically user controls, everything seems to be ok, but sometimes i am getting a 401 error when the app does a async requet for the updatepanel , but the fedauth cookie is still there and with valid lifetime, also the sts session cookie.
I tried to implement sliding sessions but the error seems to be still there
wandering if someone could shed some light here.
Btw, my web.config on the client app, looks like this
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true" persistentCookiesOnPassiveRedirects="true" issuer="https://stsissuerurl" realm="http://webapp.com" requireHttps="false" />
<cookieHandler requireSsl="false" persistentSessionLifetime="05:00:00" />
</federatedAuthentication>
regards
Have you enabled WIF tracing and seen if any clues there? WIF Tracing
I am using spring security for my application. Following are some lines from my applicationContext-Security.xml to set access as ROLE_USER for /offers and /add links and no filters for /list link.
<intercept-url pattern="/list*" filters="none" />
<intercept-url pattern="/offers**" access="ROLE_USER" />
<intercept-url pattern="/add/**" access="ROLE_USER" />
I want to show LOGIN link when user is not logged in and when user logs in to system then this link should be replaced by LOGOUT.
For that I tried following code in my jsp page.
<security:authorize ifNotGranted="ROLE_USER">
Login
</security:authorize>
<security:authorize ifAnyGranted="ROLE_USER">
Welcome <security:authentication property="principal.username"/>!
| Logout
</security:authorize>
When I am on /list link, It shows "LOGIN" link.
After login if user redirected to /offers or /add link then it shows "Welcome UserName | LOGOUT" which is working as per requrment. But Problem is, when user logs in and redirected to /list page then also it shows "LOGIN"(USER is already logged in) It should show "Welcome UserName | LOGOUT"
Help me in this scenario, What should I do to get it working?
Thank you in advance.
I found the solution, may be useful for others who are looking for same question.
Remove line below from security XML file.
<intercept-url pattern="/list*" filters="none" />
And code will work. It is because, when you specify filters="none" to certain link, then your context do not return granted authority to your jsp page. So when we redirect to list page after logging in, authorize tag says that its not authorized as ROLE_USER and execute following lines,
<security:authorize ifNotGranted="ROLE_USER">
Login
</security:authorize>
So just remove filter from that link.