I am quiet confused about how to find the technical solution of my business need. I just want to be able to give third party web apps a temporary URL to a specific user so he can access his account without log in.
I have though about a certificate that I use for every external portal. So When I get a request from them with a specific address I send them a redirect URL that is available for 5 minutes.
My application is build over .NET MVC.
Could somebody help me find out how to implement this need ?
You could generate a token and set an expiry date and send the token as query parameter and create an authorization attribute class to check if you have the token and it is valid or any other authorization you have.
You have many ways to do it but you can begin with Basic Authentication which I ended up implementing. I advice you to read the whole tutorial, any misleading could end you up to a non working code with lots of headaches.
If you need more powerful security you can go for Certificate Authentication where you have to provide your clients with client certificates.
These link1, link2, could be useful too if you don't have experience dealing with certificate generation and implementation.
Related
I'm building an application in WPF that is client side and will only depend on external API.
To this point I could use open API which I build in RestSharp and everything worked well. But from last week this API uses CAS authentication, so to use them I need to be authenticated. API I want to call is in external server. They have two API's and my assumption is that if I will log in on their site using CAS then I will be able to use this auth for my API calls for second API.
I'm new to SSO, CAS and security overall, so this was my first thought: I will build WebBrowser control, get returned TGC cookie and use ticket from it to use in requests I will be making. But this failed, setting cookie still got me and 401 error and from what I understand from CAS auth for now, TGC is a go to for checking if I'm an authenticated user in current session?
My next thought was to use some CAS c# library. Unfortunately all of advices / libraries focus on creating CAS in .NET projects. Is there some library which will provide a way to log in to CAS auth and then allow me to make API calls?
I hope this makes sense and I didn't messed up things completely. I'm new to secutity and I will be grateful for any help or guidance how to approach this problem. Things I have: API specification (endpoints paths) and username and password to log in to the system.
I have been asked to implement integration with a SAML 2.0 IdP for user Authentication purposes. I have never worked with any federated authorization processes so this is all new to me so please forgive if I am asking a stupid question but here it goes.
For My needs all I want is to send a SAMLP Authentication request. If I get a response that says the user is valid I will give them access to my system which will have a user id that matches what is returned. From that point on all authorization is to be performed by my system and I do not need to send a token with each request to the SAML IdP. After they log in I am done with the IdP.
Many of the questions and examples I see on here and other sites include adding extensive libraries to my project. When I look at them and the documentation around them they all seem to want to either perform the authentication with every request through an IIS Module or through integration with the MVC routing mechanism.
So now to my question. Can't I just create the XML myself and stick it on the the querystring as the SAMLRequest value? Then parse the response XML that comes back for the values I need? If this is a valid way of doing it does anyone have some example code that does this?
Any help would be greatly appreciated
The flow that you describe is how things are normally done: One SAML2 request to the Idp to authenticate the user, and then setting a session cookie for all subsequent requests.
Don't create this yourself unless you want to investigate substantial time to understand SAML2 and XML signature validation rules. They are complex and most custom implementations get it wrong, resulting in compromised security.
My own library, Kentor.AuthServices works the way you want. Even though it comes either as an httpmodule, an mvc controller or an owin middleware, it only interfers with the first requests that make up the actual sign in. All subsequent requests are just passed through and the session cookie mechanism handles the session authentication.
I developed a web application that has a "demo page". One of the business rules is to get rid of the login/password thing to the trial users - while requiring the user to have a valid e-mail to start the trial and log all the user's actions individually.
In my mind, it was easy: let's just use a "token" in the URL as a parameter. We ask the user to enter the e-mail and then send the access link with the generated token - pretty much like an API, but instead JSON and XML, we display an HTML with JS. Same thing in my mind.
Like this:
https://www.example.com/trial?token=abcdef123456
It was running well until I noticed that google had indexed one of our access links with a valid token. How?
For me, this is VERY strange. We have APIs that use the same functionality - passing the access token in the URL - for years. Google's and Microsoft's APIs works just like this. The only difference is that I am returning HTML instead of JSON.
We have digital certificates, HTTPS with SSL/TLS encryption. We use RNGCryptoServiceProvider to generate a secure token. We only send the tokens over a secure channel (e-mail or inside our https website).
What could have happened? And what can I do to prevent it?
My guess: Google Chrome, maybe?
Its is likely that one of your clients, whom you sent the access URL with embedded token ended up posting it to a forum/blog/page which eventually got indexed.
Scenario:
For eg. I got your URL via email and decided to blog about how cool your service is and list the URL to let people take a look at it. Google bots come scrape my blog page, come across your link, go visit it and then index it against all relevant keywords that are on that page. Next, when one searches for a relevant keyword pertaining to your website/business, this URL is displayed as a search result.
Self Test:
Try searching for that exact URL on google to reveal any page that might list it.
Remediation:
robots.txt
Why doesn't this happen for your JSON APIs: APIs are for machine consumption. Developers know the significance of a API key. Unless a developer is careless/stupid enough to post the API endpoint with the api key in it on a blog, its not likely this will happen.
In case of a 'demo' link, a business person might not know if he is not supposed to forward this link unless you state so in the email.
I need to implement authentication for some web services that we will be hosting. I want to use open standards, so I am interested in OAuth.
I will be using WebAPI for these services.
So here's where I'm running into trouble: Most (or maybe all) of the Api Key/OAuth scenerios that I have read involve (at some point or another) a user sitting in front of a screen.
I need to put together an API that a business partner will be calling. The calls will come from an automated process -- nowhere in the chain will there be a person who can be redirected to a web site with logon credentials.
However, I don't want just anyone coming around and calling my services.
So, I read about OAuth, and how it uses a shared secret to sign each request, and I think that's what I'm after. (I would either set up a session key, or could consider making one of the parameters a "ticks" value, and only accept requests within a short timeframe, etc)
I was kind of hoping that I could use DotNetOpenAuth to accomplish this (or something like it), but every example I come across begins with "the user gets redirected to a login page). I only need "2 leg" authentication.
Is there an example of using DotNetOpenAuth to do this?
Is there a better way to go?
If you are looking at OAuth 2 then the flow you are describing is the Client Credentials Grant
This kind of "two legged" / "service account" type flow is one that doesn't have a web page based flow.
DotNetOpenAuth supports the Client Credentials Grant. You can see an example of it in action here; however, be aware even though the author states it is the "Resource Owner Password Credentials" grant it is actually the Client Credentials Grant.
The blog post above was a little out of step with the latest DotNetOpenAuth code base but these are quickly identified and altered.
I believe that as it stands the DotNetOpenAuth only supports issuing a Bearer token using Http Basic authentication. There are other more exotic extensions OAuth 2 with a similar flow e.g. the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (but as stated this is not yet part of DotNetOpenAuth).
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.