Checking all the available libraries, we decided to use ItFortec SAML library. The login happens without any issues, but it redirects to destination page. Before it redirects is there a way to capture the SAML response and store claims attributes in a variable.
You can use free tools like Fiddler (https://www.telerik.com/download/fiddler), or use Saml Tracer for Chrome browser (extension). Both have numerous tutorials how to capture the full trace of the saml flow between IDP and SP. Hope this gets you started, if not post your question.
Related
I'm trying to do an Authorization request following the documentation about it on Microsoft (Getting access on behalf of a user: https://learn.microsoft.com/en-us/graph/auth-v2-user). I'm making the request using Azure's Logic Apps. I already made an app registration in Azure AD and gave it the following permissions (I used the app for a few different requests before so that's why it contains a lot of unnecessary api permissions). I already succeeded in getting access without a user (https://learn.microsoft.com/en-us/graph/auth-v2-service). Now I really don't know what I'm doing wrong, so if anybody has an idea of what it is, please let me know. I will try to explain as carefully as possible using screenshots so you guys get the idea of what I'm trying to do.
On the first screen below you can see the api permission I added to my app registration. For this request I'm only asking authorization for the one with arrow next to it(as you will see later on).
On the second screen you can see the HTTP post request I'm trying to make to the authorize endpoint. I blurred out the Tenant and Client_id for privacy reasons. I only added the required parameters in the body as described by Microsoft. In the scope parameter you can see the api permission I'm asking permission for.
On the third screenshot you can see the output of the request. Instead of getting an Authorization code as requested, I get an HTML body.
When I paste that HTML body into a browser it gives me the following result:
I have no clue what I'm doing wrong. I tripled checked to make sure cookies are enabled, made sure third-party cookies are not disabled and added login.microsoftonline to my trusted websites.
I'm starting to think I'm doing something very simple wrong, but I can't figure out exactly what. Any help is welcome! :D
Sorry can't add a comment so posting as an answer
What you are trying to implement is the Authorization Code grant flow of OAUTH 2.0. In Authorization code grant flow following steps occur
1) User is presented with the scopes that an application requires when accessing certain resources,
2) The user authorizes this. and the user is redirected to a redirect url
3) The application then exchanges the code sent with the redirect url to get the actual token which in this case will be sent to the Microsoft Graph for validation.
4) User then sees the information pulled.
The major crux of Authorization Code grant flow is that "User Authorization is required" This basically means that this flow is used when the call is invoked from a browser client where the user is actually interacting. This flow should not go through the Azure Logic Apps. If you want a service or a daemon to access the resources in that case you should use Client Credentials Grant flow
I've looked at the following SO example which says that a unique token must be placed in the URL posting data.
That way if anyone creates a url like http://example.com/vote/30 it won't work because it does not contain the unique token.
I'm also reading through this tutorial which places a XSRF-TOKEN in the header. I'm just curious as to how this provides protection because if the user is logged in and clicks on http://example.com/vote/30 won't that request still pass?
In other words if I'm logged in and someone sends me the http://example.com/vote/30 link in an email and I click on it, wont that link still pass the the CSRF check, or will the browser not send the required headers since the the link will most likely open in a new tab?
It seems like the when the link is clicked the new tab will request the page. However the new browser window will not have the same XSRF-TOKEN that the logged in browser window has? Am I understanding this correctly?
CSRF
This above article offers a good explanation of what a CSRF attack looks like. The basic premise is you don't want a malicious website to make use of a valid session you have on another website. You prevent this by using a CSRF token. The malicious website doesn't have access to this token so they won't be able to make any POST requests on your behalf.
Spring Security CSRF
When using Spring Security, CSRF protection is enabled by default. The token is automatically configured when using supported HTML templating engines like Thymeleaf, but you can easily set it up on your own by following the documentation.
I'm trying to understand how an saml authentication flow could work in a mobile environment where the client (AngularJS based), api server (Node & passport based), and idp exist on different domains.
From what I've gathered the general practice is to have the server return a 401 to the client if there's no authentication present (i.e. the client didn't include a bearer token in the request). The client understands that a 401 response indicates to open up the login endpoint on the server. When the login endpoint is opened it makes a passport call to the auth provider (which redirects the user to the auth provider's site) and supplies a callback URL. When the user authenticates, the auth provider redirects to the provided callback URL, which allows the server to retrieve information from the auth provider's response and construct a token of some sort (e.g. JWT) that can be used by the client (i.e. included in the headers) when making REST calls to identify itself.
My question is: How does the client get the token from the server? Because we're in a redirect-based authentication flow, I can't just return token from the callback function; that would just display the token in the browser without handing it off of to the client. Does the server just issue a 302 redirect pointing back to the client domain and include the authentication token in a header? Maybe I should not redirect from the client to the server in the first place and instead window.open() and use window.opener.postMessage or is that too old fashioned/mobile-unfriendly?
This question talks about authentication against a SAML IDP, but I'm interested in getting more details specifically about that last bullet point and how it would work with an AngularJS-based client.
Many examples I've seen online are either a single domain using OAuth/SAML (passport-saml-example), which avoids the issue of having the client exist on a separate domain, or use two domains with basic authentication, which avoids the issue of redirecting to some third party for authentication, but I'm having trouble finding good examples that uses all the bits and pieces I'm trying to work with.
This blog post seems very close to what I'm trying to accomplish (see googleSignInCallback) and uses a 302 redirect like I imagined but that solution relies on explicitly knowing the client URL to redirect to, which seems like it could be problematic if I wanted to support multiple client types (i.e. Native applications) in the future.
Eventually I was able to work together a solution by having my application open a browser window (Cordova's InAppBrowser) to a SAML-enabled application, have that application complete the normal SAML flow, and then that SAML-enabled application generated a JWT. My mobile application was then able to extract the JWT string from the browser window with the InAppBrowser's executeScript functionality. Then I could pass that JWT string along to my API server, which was able to validate the JWT is properly signed and trusted.
After I implemented my solution I saw that there was similar functionality available on github:
https://github.com/feedhenry-templates/saml-service
https://github.com/feedhenry-templates/saml-cloud-app
https://github.com/feedhenry-templates/saml-cordova-app
Hopefully this helps anyone else trying to deal with this issue!
My app uses JS Facebook API to use Facebook as a login/pass. Here what happens when you try to login.
User click on the Facebook Login Button
Facebook Authenticates
If Success. I grab the Facebook ID and Name of the user
Calls on my REST API on my APP to check and see if the that FBID is registered in my system.
If Registered, I write the session to verify that the user is authenticated.
This is great since I don't have to store usernames and password. But I am worried that someone will just use a REST API debugger like POSTMAN in chrome and just send a Facebook ID and the name of the user and they will be authenticated.
My question is what is the best way to secure my end that will prevent apps like POSTMAN to just input the fields needed to authenticate? Am I missing something? Can anyone recommend a strategy for this?
Or is using CSRF token the only way to combat this? I am using FuelPHP as a backend and doing a single page app using AngularJS with NgRoutes. But every time I enabled the CSRF on fuel, the token passed does not match what it was in the back-end.
I am under the impression that this is due to that the javascript token function is in the main page, where the ng-view. I know this might have something to do with the ngRoutes.
http://fuelphp.com/docs/classes/security.html
Use Fuel's Auth package. It has Opauth integration which does all the above, and for an entire list of social media platforms, not only facebook.
Always try not to reinvent the wheel, assume someone else has had the same challenge, solved at, and shared the solution with the community.
I am attempting to access a link to a document within an application. When I click on the link I am directed to authenticate via SAML (Ping Federate). Once I am logged into the application the link is lost and it takes me to the application's home page. Does anyone know how I need to configure SAML to remember the link after I authenticate. I am under the impression that it has some thing to do with Deep Linking and/or RelayState. I have Deep Linking turned on in the app and my relay state variable is "RelayState". Any help would be appreciated. Thanks!
#andy-k-ping-identity is right in his comment. When your app that is deeply linked to determined that it doesn't have a session, it needs to redirect to the PingFederate SP's start SSO endpoint w/ the deeply linked page as the TargetResource. After all the SSO is done, PingFederate will cause the user to be redirected to that page. So, for example, the deeply linked app should return a 302 like this if the user doesn't have a session:
HTTP/1.1 302 Found
Location: https://fs.sp.com:9031/sp/startSSO.ping?TargetResource=https://sp.com/deep-link&...
HTH!