I am trying to integrate my spinnaker application with Okta. I created application in Okta.
Spinnaker Dashboard Application configuration:
I have configured my gate-local.yml file accordingly.
saml:
enabled: true
metadataUrl: file:/opt/spinnaker/config/metadata.xml
keyStore: file:/opt/spinnaker/config/saml.jks
keyStorePassword: <password>
keyStoreAliasName: saml
issuerId: <issuerId>
When I hit url http://localhost:8084 i am getting redirect to Okta login page. Once I successfully logged in I am getting error message as
{"error":"Unauthorized","message":"Authentication Failed: Incoming SAML message is invalid","status":401,"timestamp":1524402208502}
This is SAML flow. You are likely hitting step 4 and not passing it.
You should use SAML Tracer to check.
Related
I am setting up an IDP initiated SAML authentication flow
One of our clients will send an SAML assertion request to us by clicking a link within their internal system to access our application - so we act as the service Provider (we use Identity Server from Duende for Authentication)
We are looking at using ITfoxtec.Identity.Saml2.MvcCore library
AS we are going with an IDP initiated SAML flow, I wanted to check to know if
As an SP (Service Provider) do we only need to have an ACS end point for the incoming SAML Assertion. On receiving the Assertion we can process it to get the Claims we need and if it meets our requirements we can give the access to our application.
Do we need to send back any notification to the IDP that sent us the Assertion ?
Once verified after receiving the Assertion, do we set the access token in our Identity Server or do we get a token in, the assertion. We need periodically need to check if the user associated with the incoming Assertion is still authenticated in the IDP. Hence I was wondering if the IDP would issue a token with an expiration date/time, if not then would we have to initiate a new SP initiated SAML flow to check if the user is still authenticated with the Client IDP ?
DO we as an SP need to issue our own Access Token ?
For Logout, we only want to log the user out of our system (So remove our token if we issue one, we do not want to log out the user from their IDP?
Do we need to simulate login in our Identity Provider or will that happen automatically when we add the SAML2 to our Authentication method in our startup.cs
Do we use the ITfoxtec.Identity.Saml2.MvcCore library as we are using Duende IdentityServer in a .netCore 5.0 setup
is this possible with ITfoxtec library ?
services.AddAuthentication()
.AddSaml2(options =>
{
var spOptions = new SPOptions
{
EntityId = new EntityId("https://localhost:44373/Saml2"),
ReturnUrl = new Uri("https://localhost:44373"),
MinIncomingSigningAlgorithm = "http://www.w3.org/2000/09/xmldsig#rsa-sha1",
};
options.SPOptions = spOptions;
options.IdentityProviders.Add(new IdentityProvider(new EntityId("https://www.example.com/SSO/SAML/App"), options.SPOptions)
{
AllowUnsolicitedAuthnResponse = false,
MetadataLocation = "https://www.example.com/SSO/SAMLMetadata/App",
LoadMetadata = true,
});
});
Yes and you only need the ACS endpoint. You can also do logout if it is supported by the IdP.
No
You resave a SAML 2.0 token in the Assertion which has a lifetime. To check user state you either need the IdP to start a new IdP initiated login or you can start a SP initiated login, if supported by the IdP.
No. That do not has anything to do with the SAML 2.0 integration.
In IdP initiated scenarie the SP usually do not request the IdP to logout.
You need to simulate IdP initiated login, you can use this code sample.
You can integrate ITfoxtec Identity Saml2 into Duende IdentityServer but I do not have a sample on that.
I am trying to setup saml sso configuration for my application which is deployed in websphere.
Idp- Azure AD
SP - Websphere application server when my target application deployed
Done TAI configuration as per the Ibm document . But when I hit the test button from idp I could see the saml response in network tab. but i couldn't login to my application and also didn't get any trace related to saml in log files also however i have enabled logs for saml in Troubleshoot. My doubt is sometimes am getting trace which are related to TAI during server stop. For each request should i be getting TAI trace ? and why my saml response not getting intercepted in TAI. How exactly the interception happen with saml response and how do we get to know that saml response got validated.
[15/4/21 16:18:42:855 IST] 00000096 TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor loaded successfully
acs url -> https://localhost:/browserTest (which is my actual target application url)
metadata and signing certificates also imported correctly.
Thanks for your help.
The acs URL has format like this:
https://<hostname>:<sslport>/samlsps/<any URI pattern string>
if you want to use your application URL
https://localhost:/browserTest
as acs URL, this UR must be able to accept HTTP POST.
I am integrating Okta in my React application for SSO. I use the following method to create token using redirect:
https://github.com/okta/okta-auth-js#tokengetwithredirectoptions
I am using https://www.npmjs.com/package/#okta/okta-auth-js package.
Users are directed to the Identity Provider (idp) in order to authenticate and then redirected to Okta once verification is successful.
The SSO works fine but when I keep the React application idle for sometime, I am getting the following error:
OAuthError - Unable to process the username transform. A required property is missing. Missing field email.
It looks like you have configured email as the incoming claim from your IDP but Okta can't find it in the incoming assertion/token.
If SAML Response has the status as "status:Responder",
According SAML spec:
urn:oasis:names:tc:SAML:2.0:status:Responder The request could not be performed due to an error on the part of the SAML responder or SAML authority.
We expect the IDP should send the error message along with the response.
In ADFS event viewer, we can find out why SAML request failed, however we don't have access to ADFS sever in production environment.
Is it possible to get the error message inside SAML response in case if the authentication fails?
So I am trying to setup Okta as an identity provider, and I want to login to an application using the Service Provider initiated workflow. I've setup the template SAML 2.0 application in Okta and setup the entry point and SAML certificate on the Service provider. The Service Provider initiates the workflow just fine, a popup opens with the Okta login dialogue. But once the login is complete I am taken into the Okta portal with a list of my apps. What should be happening is a re-direct back to the Service Provider so that it can use the userID to login the user there.
I followed the instruction here for setting up the IdP https://support.okta.com/entries/23364161-Configuring-Okta-Template-SAML-2-0-application
Here is what my config in Okta looks like
Application Label: App Name
Force Authentication: no
Name ID format: EmailAddress
Recipient: https://serviceprovider.com/_saml/validate/okta/
Audience Restriction: https://serviceprovider.com/
authnContextClassRef: Password Protected Transport
Destination: https://serviceprovider.com/_saml/validate/okta/
Response: signed
Assertion: signed
Request: uncompressed
Default Relay State: Leave blank since we are only doing SP initiated workflow
Post Back URL: https://serviceprovider.com/_saml/validate/okta/
Attribute Statements: none
Group Name: leave blank
Group filter: leave blank
I don't see any errors in the Okta portal or in the Okta administration panel, so I can't figure out why it is not completing the workflow and re-directing back to the SP.
Is there a place in Okta to see any errors that might be getting thrown by the process?
Anyone know what might be up?
I had a similar problem a while back. In my case, the "Rquest" was set to "compressed". changing it to "uncompressed" solved the issue. But in your case I see it is already "uncompressed"...
However, try to contact OKTA's support - they can help you out.
The answer is different depending on the type of SAML HTTP BINDING used for the SAML Authentication Request.
For HTTP Redirect Bindings you need to set the Okta Request to "compressed".
For HTTP POST Bindings you need to set the Okta Request to "uncompressed".