I am implementing service provider-initiated SSO for Salesforce where the service provider will be Salesforce and the identity provider will be a lambda code. The lambda code will allow a user after verifying the user's mobile number. Once the mobile number is verified a SAMLResponse will be sent by lambda.
I have configured SSO on Salesforce as below:-
I am also able to generate a valid SAML response and have validated it on Salesforce SAML validator as below:-
I have created a login page that will be redirected from Salesforce.
I have also created an API to get a unique SAML response every time for the given federation ID as below:-
https://qodz4saz9a.execute-api.us-west-2.amazonaws.com/v1/generate-saml-response?FederationID=rahul#xyz.com
URL for Salesforce login page is- https://im--partial.my.salesforce.com/.
After all this setup I am able to get redirected to the login page I have created from Salesforce by selecting "Log In with a Different Account" option and then selecting "Twilio" as below:-
Salesforce is redirecting to the login page with a SAMLRequest parameter in the URL as below:-
http://salesforce-sso-page.s3-website-us-west-2.amazonaws.com/?SAMLRequest=fZJRc6IwFIX%2FC.....
I am not sure how to proceed from here and allow login to Salesforce from my login page. Once the user enters a mobile no and OTP, I am redirecting the user to below URL -
https://im--partial.my.salesforce.com?SAMLResponse=PD94bWwgdmVyc2lvbj0i.....
Here I am using SAMLResponse as a query parameter to pass the base 64 encoded SAML response for login to Salesforce. But I am not sure if it is a correct way to authenticate and login to Salesforce.
After entering the OTP(test OTP is 1234) I am getting the below error.
I am not at all using the SAMLRequest generated by Salesforce for generating the SAMLResponse for now.
I have gone through many documents but couldn't find a way to pass the SAMLResponse to Salesforce for login. Please let me know if anybody has any idea about it or if I am following the wrong steps.
The SAML response is sent to the service provider in a specific "way", the protocol refers to this as a binding. In this case the expected binding is HTTP POST. With HTTP POST as your binding, the SAML response must be submitted in a body of HTTP request sent to the service provider via a POST method. The Login URL listed in the Single Sign-On Settings screen is the endpoint where the SAML response should be POSTed. It might look something like this:
POST / HTTP/1.1
Host: im--partial.my.salesforce.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response
Do you need to worry about the SAML request? It depends on your workflow and desired end-user experience. The considerations that go into this decision deserve their own SO question. Meanwhile, take a look at SAML Technical Overview for a summary of these workflows.
Last but not least, this whole sequence of authentication via your mobile number is supported by Salesforce out of the box on some Salesforce products.
Related
We have a website which we use to download our invoices from. We want to automate this process.
We do have username and password given to us to login to this website.
When I check network trace through developer toolbar, its clear that they are using SAML based authentication.
Questions is, can I automate this authentication just using Username/Password I have? or Does Identity provider has to allow this automated authentication from their side?
I could find their Identity providers URL, but passing Post request to IDP to get SAML response is not working (Was hoping to receive SAML assertion)
If IDP does not accepts only username, where does passwords come into picture? Does Service provider validates password before requesting assertion?
We are trying to find unattended ways to get these invoices.
I've configured Cognito to use SAML Identity Provider and did all the setup on AD side, AD accepts the request and allow me to sign-in, then it responds to the configured idpresponse endpoint with the SAMLResponse form data value as you can see in the image below, but Cognito returns a 302 redirect with
location: http://localhost:3000/auth/callback#error_description=Error+in+SAML+response+processing%3A+No+SAML+assertion+found+in+the+SAML+response.+&error=server_error
I'm not sure what is going on, I tried to modify the POST request to idpresponse via curl and it is definitely reading the SAMLResponse form data because if I modify it I get invalid response error.
How can I troubleshoot it?
I am trying to setup SAML using SP initiated sign on in OKTA (IdP) using my Windows Application (SP) however i get a 400 bad SAML request after IDP authentication of my credentials. Instead of redirecting back to the application URL (SP) i get a 400 Bad SAML request.
My SP URL - https://sampleapp.company.com/appname/default.aspx
My SAML ACS URL - https://sampleapp.company.com/appname/SAML/authenticate.aspx
ON the SP side i have added the Idp connector URL and the certificate key (no trailing spaces) to the web.config.
On the OKTA configuration I have added the SAML ACS url in all the 4 sections
1) Single sign on URL
2) Recipient URL
3) Destination URL
4) Audience URI (SP Entity ID)
Name ID format is - Unspecified.
I dont see the 'Compression' menu on the configuration page. Rest of the advanced settings are kept with their default values.
I have tried playing around with the Default Relay State section as well but no use.
I hit the SP -> redirect to OKTA page -> Enter credentials -> 400 Bad SAML request.
Hit the Home button -> Hit the application chicklet -> Log into the application succesfully (this is Idp initiated) which works fine.
I have tried all the links and suggestions on the OKTA forum but cant get past this 400 bad SAML request. Is there something incorrectly set up in the OKTA configuration?
Any help would be appreciated :)
Thanks
The "Single Sign-on URL" should be the SAML ACS URL.
The Audience URI must be the entity ID of the SP, which is usually not the ACS URL.
As far as I can tell, the Recipient URL doesn't make a difference for SP-initiated flow, but I couldn't find any documentation about it.
I am trying to access the below URL from SoapUI which Retrieves metadata of a specific adapter.
https://www.example.com/worklightadmin/management-apis/1.0/runtimes/myruntime/adapters/myadapter?locale=de_DE
When I am accessing this URL from SoapUI. I am not sure what to give in its header and
I get
HTTP/1.1 401 Unauthorized
But when I use it in browser it asks me to login to worklightconsole so this would be granting access as a admin.
Can some one help me in understanding how to use the above URL in SoapUI and get success response.
Since you are getting 401 Unauthorized, it clearly says that you are trying to access the URL without providing any authorization information. Can you find out from SoapUI where you can provide the authorization information for the request? Basically you can select the 'Basic Auth' and provide the user name and password. For Http client like Postman there is an authorization tab, where you can select the authorization type and then username and password. It should be similar for SoapUI too
I'm trying to wrap my head around 3-legged authentication to secure a restful API.
Currently I have a client application at app.host.com which needs to be accessed by multiple users with different account permissions and data, as well as the JSON RESTful api which holds all data at app_api.host.com
For 3-legged auth, I understand I first need a consumer key and secret belonging to the client app.host.com... I also understand an unauthorized request token must be provided by the service provider, which is given to the client, which is then redirected back to the service provider for authorization with a login dialog.
So does the login dialog then exist as a user interface on the API host at app_api.host.com? Doesn't this defeat the purpose of me building a purely JSON restful API separately to the client?
Or can I build the login dialog on the client which would then post the user/pwd details to another auth endpoint on the API and provide a 200 code when the request token is authorized? And then in turn the client would ask for permissions from the user which would again be posted to another endpoint which then responds with the appropriate access token for that user?
TL;DR: Am I able to have the login dialog exist on the client, which then posts data to the service provider? All guides I've read suggest having the dialog on the service provider, which in this case would defeat the purpose of having the api as a separate app altogether. How should I go about building this? Any available guides?
OAuth 2.0 defines different flows to use with different clients, depending on how much you trust the client.
Authorization code
The first and most secury flow is the authorization token flow. It is used with a traditional web application in which you can store secrets relatively securely (only people with admin privileges should have access to the client ID and secret stored in the configuration).
When the user (resource owner) wants to authenticate, the user-agent is redirected to the authorization server which belongs to the domain of the resource server (the data the client wants to consume, for example Facebook or Google). The authorization server presents the user with logon UI. When the user authenticates successfully, it presents the consent UI to ask if the user wants the client application to access the resource. If the user consents, the user-agent is redirected back to the client application with an authorization code. The client application can now use this code, its client ID and secret to talk to the authorization server directly and get an access token. In this flow, the access token is never in the hands of the user-agent.
Implicit flow
In the implicit flow, the user-agent (here typically a native (mobile) application or JavaScript client) redirects to the authorization server or opens a browser window to navigate to the authorization server. When the user authenticates successfully and grants permission to the client application, the access token itself is returned to the client. So the user-agent never sees the username and password the user enters (as this happens on a HTML page that is controlled by the resource server), but does have control over the access token.
Resource owner password credential flow
Here the user-agent is fully trusted and asks the user for username and password. It then communicates with the authorization server to get a access token. Even though the user-agent knows the credentials of the user, it only uses them once to get an access token. It does not need to send them along each request to the resource server.
So to answer your question, you can build the login dialog in your app if you think your users will trust your application enough to give you their credentials. Otherwise you should probably go for one of the other flows. You can read more on OAuth 2 here and here.