Using the onelogin sample app as SP with sso circle as IdP, login via SSOCircle IdP works, but the LogoutRequest, after being validated, returns a LogOutResponse with StatusCode Requester instead of Success :
<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="xxxxxxxxxxxxxxxxxxxxx" Version="2.0" IssueInstant="2018-03-28T07:50:49Z" Destination="http://localhost:8080/onelogin-saml/sls.jsp" InResponseTo="ONELOGIN_hexahexahexa">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.ssocircle.com</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:LogoutResponse>
IdP initiated Logout works.
I cannot figure out what am i missing in the properties configuration :
onelogin.saml2.sp.single_logout_service.url=http://localhost:8080/onelogin-saml/sls.jsp
onelogin.saml2.sp.single_logout_service.binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
onelogin.saml2.sp.nameidformat=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
onelogin.saml2.idp.single_logout_service.url=https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/publicidp
onelogin.saml2.idp.single_logout_service.response.url=
onelogin.saml2.idp.single_logout_service.binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
Any input would be warmly welcome.
thanks to the onelogin contributors, i could solve the problem by storing the nameId, sessionId and nameIdFormat into the session at login, and then use them as parameters when calling the logout method. see closed issue for full code here.
Related
I have tried using the sso url as mentioned "Single Signon Service"https://auth.pingone.asia/{env}/saml20/idp/sso , and issuer as https://auth.pingone.asia/{env}. but getting ErrorCode: INVALID_ISSUER - Unable to find application for spEntityId: 'https://auth.pingone.asia/{env}' in environment {env}.
Please help me to understand where exactly I have wrong configuration.
Check if you have created a SAML Application, if not, try creating it with https://apidocs.pingidentity.com/pingone/platform/v1/api/#post-create-application-saml-protocol
Note: acs url is the place where you want PingIdentity to redirect after login authentication is completed. You will get a SAMLRespose also posted there.
(OR) You can create SAML application directly from the PingIdentity console itself by selecting Add Application, Select SAML as type, and Set Manual Saml configuration by specifying entity id (something unique) and ACS url.
Go to ping console dashboard, and check the Entity ID of the application, it should match with your AuthnRequest saml:Issuer
Example if your dashboard is like this with Entity ID "test",
then your AuthnRequest should look like this:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="test"
Version="2.0"
IssueInstant="2022-09-19T16:46:59">
<saml:Issuer>test</saml:Issuer>
</samlp:AuthnRequest>
Note the line: <saml:Issuer>test</saml:Issuer>
I implemented what is described here: Signup with email invitation
This works flawlessly when the Azure app service uses the B2C Azure AD for authentication\login, that is, the invitation e-mail is sent when I'm logged in through an account authenticated by the B2C AD.
Now I have another app service pointing to a B2B Azure AD for user login\authentication and so the invitation e-mail is sent when I'm logged in through an account authenticated by the B2B AD.
The email with the invitation link that points to the B2C AD is sent correctly. However after clicking the link, the B2C signup invitation policy takes action and I'm presented with a 401 error (unauthorized). This looks like the B2C policy can't access the metadata endpoint set in the policy configs for any reason...
The message being displayed is:
Correlation ID: 78292d04-7184-42d0-ac2d-a60bb98a532f
Timestamp: 2019-09-20 16:19:25Z AADB2C: The metadata endpoint
'https://mywebsite.azurewebsites.net/.well-known/openid-configuration'
returned the following status code: '401'
This is the custom signup invitation policy <ClaimsProvider> in which this metadata endpoint is specified:
<!--This technical profile specifies how B2C should validate the token, and what claims you want B2C to extract from the token.
The METADATA value in the TechnicalProfile meta-data is required.
The “IdTokenAudience” and “issuer” arguments are optional (see later section)-->
<ClaimsProvider>
<DisplayName>ID Token Hint ClaimsProvider</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="IdTokenHint_ExtractClaims">
<DisplayName>ID Token Hint TechnicalProfile</DisplayName>
<Protocol Name="None" />
<Metadata>
<!-- Action required: replace with endpoint location -->
<Item Key="METADATA">https://mywebsite.azurewebsites.net/.well-known/openid-configuration</Item>
<!-- <Item Key="IdTokenAudience">your_optional_audience_override</Item> -->
<!-- <Item Key="issuer">your_optional_issuer</Item> -->
</Metadata>
<OutputClaims>
<!--Read the email claim from the id_token_hint-->
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="shardTenantId"/>
</OutputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
My question is: why this 401 (unauthorized) is being thrown? When I try to access the metadata endpoint: https://mywebsite.azurewebsites.net/.well-known/openid-configuration it opens just fine and returns the required json output:
{
issuer: "https://mywebsite.azurewebsites.net/",
jwks_uri: "https://mywebsite.azurewebsites.net/.well-known/keys",
id_token_signing_alg_values_supported: [
"RS256"
]
}
This is the web API method that outputs the json described above:
[AllowAnonymous]
[Route(".well-known/openid-configuration", Name = "OIDCMetadata")]
[HttpGet]
public HttpResponseMessage Metadata()
{
var json = JsonConvert.SerializeObject(new OidcModel
{
// The issuer name is the application root path
Issuer = InvitationHelper.GetBaseUrl(),
// Include the absolute URL to JWKs endpoint
JwksUri = Url.Link("JWKS", null),
// Sample: Include the supported signing algorithms
IdTokenSigningAlgValuesSupported = new[] { SigningCredentials.Value.Algorithm }
});
var response = Request.CreateResponse(HttpStatusCode.OK);
response.Content = new StringContent(json, Encoding.UTF8, "application/json");
return response;
}
I even tried adding [AllowAnonymous] annotation to the API method but that didn't make any change.
Why can't the custom signup invitation policy access the metadata endpoint that is in an app service hosted on a different B2B AD tenant?
NOTE 1: added Application Insights instrumentation to this custom policy and the only message I saw there was Fatal Exception 401 without any more valuable info:
{"Kind":"FatalException","Content":{"Time":"4:15 PM","Exception":{"Kind":"Handled","HResult":"80131500","Message":"The
metadata endpoint
'https://mywebsite.azurewebsites.net/.well-known/openid-configuration'
returned the following status code:
'401'","Data":{"IsPolicySpecificError":false,"uri":"https://mywebsite.azurewebsites.net/.well-known/openid-configuration"}}}}
NOTE 2: if you look at the <ClaimsProvider> above there are these 2 settings:
<!-- <Item Key="IdTokenAudience">your_optional_audience_override</Item> -->
<!-- <Item Key="issuer">your_optional_issuer</Item> -->
I'm not sure how to use these other 2 settings as those were not described in the doc # GitHub.
Maybe the issuer is the problem... I'm trying things here but nothing is working so far. So I decided to ask this question. I hope someone can shed some light.
I got in contact with Jas Suri through LinkedIn. He's the guy that did the last commit in that GitHub repo.
He asked me for the real metadata endpoint (the one I posted here is a dummy URL).
When he tried to access that URL he was prompted to login... what!? Login!? Yep. That answered the question. I got SSO here on my developer box and that's why I didn't catch that... but wait: I had [AllowAnonymous] annotation in that web API method, right? So why was it still asking for login!?
He promptly asked me if I had enabled Authentication on the app service level... I went to Azure Portal and checked the app service Authorization/Authentication settings. Guess what... I had it turned ON but the problem was not that directly. See the highlighted setting below:
We can keep it on, but the real problem was that sometime ago I had set
Action to take when request is not authenticated
Log in with Azure Active Directory
That was overrides the [AllowAnonymous] annotation placed on the web API method.
As soon as I selected in the dropdown:
Allow Anonymous requests (no action)
and saved, then the B2C policy started working as expected.
Anonymous access is enabled on the App Service app. Users will not be
prompted for login.
I have setup an Application that's is using OKTA as IDP. The app is SAML Based.This part is working fine.
But I am unable to log out. For this we have
1. Enabled Single Logout
2. Set the Single Log out URL (I received this from Metadata of IDP under header Identity Provider Single Logout URL)
3.Sp Issues (I received this from Metadata of IDP under header Identity Provider Issuer )
4. Signature Certificate (This is the certificate of IDP)
Now when I call the Logout URL I am receiving 403. On checking the Logs of OKTA I see the (User Single Sign out from App Failure:- Malformed Request)
Can any one please help me how to fix it.
I am assuming that I just need to call the logout URL and the session will kill off. Is my understanding correct?
Reviving a very old thread, check that you have a ?ReturnTo=<path> at the end of the logout URL.
Okta requires strictly post binding requests for logout. Please make sure you are making POST requests for logout and you are using correct entity Id in request.
I think the setting values below need to be set for sp side.
Set the Single Log out URL
Sp Issues
Signature Certificate
It is not on idp side.
I am attempting to use SP-initiated SLO with SalesForce (trying Redirect and POST) with the following LogoutRequest:
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_1583fa34b3e9426ba5885849204d6f8d" Version="2.0" IssueInstant="2017-11-14T18:42:25Z" Destination="https://myorg-dev-ed.my.salesforce.com/services/auth/idp/saml2/logout">
<saml:Issuer>myorg</saml:Issuer>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">me#myorg</saml:NameID>
</samlp:LogoutRequest>
I am using my SP entity ID for Issuer. I also tried using it for NameID SPNameQualifier. My Redirect and POST logic work for AuthnRequest. This SLO is working with OneLogin.
The error I get back is:
We are unable to log you out. Please contact your administrator for
more information.
I can not find any relevant log entries.
Which tool are you using to generate the XML?
Add the tag SessionIndex, which you can get from the login.
The SAML Response will be posted to the following url:
https://domain/sp/ACS.SAML2
But when I try to hit the url, I am not able to see the response.
Anything wrong in my approach?
Thanks & Regards,
Aswini J
A few things assuming you are setting up SAML 2.0 Web SSO Profile -
What do you mean you can't "see" the Response? Are you successfully logging into the IDP and having it redirect the Browser to the PF ACS URL?
With PingFederate, the application and protocol end-points are case sensitive. You should use http(s)://www.server.com:<PF runtime port>/sp/ACS.saml2. If you simply request this value from your browser with a GET request and no SAML data, PingFed will show you a generic error template page.
If you have successfully POST'd the SAMLResponse to the right endpoint, you will see the actual SAMLResponse logged in the /pingfederate/log/server.log.