I'm writing a C# application and need to scrape some information from an rss page that only offers Http Basic Authentication.
This seems to leave me with two choices
Ask the user to input their credentials into my app (which has trust issues as the app is then a potential middleman attacker?)
Get windows to insert the credentials on behalf of my app somehow (does this facility exist?)
All the examples I've seen on SO have the username/password hardcoded in the app or passed in as parameters from somewhere unspecified. My use-case is I'd like to give this app to people who may not want to trust it with their password.
How is this usually handled? Thanks
Short answer: It is not possible with basic auth. It is generally not possible with the OS a the trusted instance.
Long answer:
The proper way to solve this would involve a procedure where your application hands control to the OS (Windows), which then asks the user "Do you trust application XY to use your identity?". After user acceptance, your application would receive a security token which you could use afterwards to make your HTTP request to get the RSS feed. The problem is, that the site in question does only accept basic auth. This means, that the "security token" is the base64-encoded username and password. So the username and password would be exposed to your application anyway.
The second problem is that the OS and the RSS site have to share a secret (i.e. an encryption key not available to you or anyone else not allowed to log in site users), to enable the OS to issue a secure token that is trusted by the RSS site.
How the problem can actually be solved
The default, real-world example for the access of web resources with third-party software on behalf of the user without knowing his password is OAuth, see for example the Facebook login flow. (However, this requires the website/resource in question to provide third-party access. As your question indicates, this does not apply for your use case.)
The pattern employed is the following:
Prerequisite: You need to register your application with the RSS service provider to obtain an application ID and an application secret.
Your application redirects the user to the login endpoint of the identity provider.
The user accepts (or declines) the access of your application to his identity and data (e.g. the RSS stream).
The identity provider redirects to your app
Your application receives a token which can be used to make authenticated requests on behalf of the user. This may involve additional steps like exchanging the token for another.
Alternative Solution (does not answer your question):
Sometimes (protected) RSS feeds can be accessed via secret user-specific URLs. Of course, the user would have to provide your application with that url.
Related
I Will try to describe this as detailed as possible.
For using the SPA, you need to be logged-in, every request is authenticated by JWT. Login is a simple form with Username and Password fields, which are sent to the server. On the server, there are two types of login (kinda) - AD and Password (determinated by the user type):
API check if username exists and determine its Type
a) if type is Password: Check if password matches the data in Database
b) if type is AD: verify password on the LDAP server
successful login returns generated JWT, which is used for all further requests.
This App is available all over the internet, not just inside the same network as the server.
I would like to have some kind of "automatic login" with Windows account (so you dont need to manually type the username/pass, but the SPA tries to login automatically when u open the Login page).
I tried many guides for something like this, but nothing seems to work properly.
I heard that Kerberos/Auth0 should do the work, but I dont know how to implement it. Also I would still need to get that JWT for further requests. Do I need some kind of Microsoft request? Azure? Anything else? (If is needed, I can create another IIS application just with Login controller).
I hope you understand what I mean, and will be able to help!
Most Modern Browsers speak SPNEGO
Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), often pronounced "spenay-go", is a GSSAPI "pseudo mechanism" used by client-server software to negotiate the choice of security technology.
It just so happens that one of those client-server security technologies it can speak is Kerberos. (Windows machines generally have kerberos availble by default.).
So to actually get .NET to use kerberos authentication you really need to enable delegation for IIS as that's what speaks to the browser.
I have searched all over for an answer to this, and not found anything that seems to answer my question. Which feels like it should be an easy one (but clearly isn't).
I have an API which authenticates using a token. This token I generate from my application - more specifically, I have a new Token Generation web call that will return a token. Currently, I pass in a cookie with the user and password information, and it uses this to identify who I am and what I should be allowed to do. This is all working absolutely fine and hunky-dory.
I am achieving this process by making the Token Generation use OWIN Cookie Authentication, which means that the cookie is read and the Identity is set. I am then able to use this identity to confirm whether the user is allowed to access the system.
What I now want to do is replace this Cookie Authentication process by authenticating against a Windows User (everything is windows based, and this will be an option so non-windows users can still use the cookie authentication route). But I cannot discover how to straightforwardly do this.
Note that I don't actually need to validate that the user is genuine or refer back to the AD at all. If you provide a windows user that matches a user in the system, you can log in.
So how can I - easily - get the requesting user into the Identity Name? Or is this not possible?
If you are looking for information on the current user accessing your program, assuming the program is running on the user's machine and is windows based, you can simply query windows for the user's username or any other publicly available information about the user.
Refer to https://learn.microsoft.com/en-us/dotnet/api/system.environment?view=netframework-4.8 for information on the Enviroment class and what it's features are.
If you could provide some code or further clarity I could help you further.
I have this scenario where an external web site is going to send some data over the network to my web app, then I have to process that info and complete a process within my app. After process completion, I need to return to the original external web with some info.
My questions is about security, how do I know that the external site making the request is actually the web site is supposed to make the request? If you can point me in the right direction would be great!
I'm using ASP.NET MVC4.
For this scenario, certificate authentication best suits. I have got many external clients consuming my service and cert authentication is working as expected.
#Mick Wasson has written this post:
http://www.asp.net/web-api/overview/security/working-with-ssl-in-web-api
You can purchase certificates from 3rd party like :
Rapid SSL :https://www.rapidssl.com/index.html
Global Sign: https://www.globalsign.eu/ssl/
The following are available options. Basic or Tokens might be good choice if your web app is a public web service.
Basic
The caller adds an HTTP authorization header containing a user name and password. Those values are essentially plaintext, using only base64 encoding for simple obfuscation. This generally requires Secure Sockets Layer (SSL) transport security (i.e., an endpoint
that exposes an HTTPS address) to protect the plaintext user name and password.
Digest
Provides a fancier method of putting the user name and password in the HTTP header that provides encryption for those values. This is intended to avoid the need for HTTPS.
Kerberos
Uses an authentication server, such as Windows Active Directory, to provide integrated and seamless credential validation. This is similar to intranet sites on Windows networks that integrate with the domain for user authentication. A lot of internal SharePoint sites use this approach so that a company's users don't have to re-enter their user name and password when they visit the intranet.
Public-Key, Certificates
Relies on caller-provided certificates to identify a user. This is not very useful in a public web site or service, but it is very appropriate for applications where the users or devices are known. An example of this approach is an internal, portable, device-based
warehousing application for tracking inventory, or maybe a set of iPads used by the sales team. The group of users is relatively small and well-defined within a company's organizational structure. Each user or device is issued a certificate that identifies him (or it) on every call to your site or service.
Tokens
Largely used when third-party token issuers are involved (e.g., OpenID, OAuth). This relieves your service of the burden of both storing and verifying a user's credentials. Here's how it works (generally speaking):
The caller first verifies the user name and password using a token issuer that your service trusts. Upon successful verification, the token issuer provides the caller with a token. Once the caller has that token, it uses it to call your service. Since your service trusts the issuer that the caller used for credential verification, your service can trust that the token securely identifies the user, and it therefore doesn't have to bother with verifying the user's credentials itself.
Source: ASP.NET Web API 2: Building a REST Service from Start to Finish.
I am looking for single sign on for my application which is built on javascript (no server side language).
Requirement:
Agent log in to Windows (user integrated to Active directory)
Open my web page
Based on who logged in to windows, my application goes to AD and pull some user
specify data (eg email, phone)
How shall I go about it?
As per my understanding I will require ADFS for this.
So:
User goes to my web page
My web page calls some Web services or web application (which is build on c#)
That will authenticate against AD FS and get claim
Either get phone number and email in claim or get username and query AD for phone and email
Return the data to my web page (build on javascript)
It seems there something wrong in my understanding!!
Please suggest more appropriate solution based on my requirement
Frankly, I can't think of a way to make it work without a server side processing. This is because the ws-federation protocol ADFS uses is not just about returning claims.
It is about returing a SAML token. The token contains claims but what is most important about it is that it is signed using the XMLDsig. How are you going to validate the token is a first big question. But there are surely external libraries that allow that.
But then, such authentication can easily be bypassed by modifying scripts in the browser. This is because the ws-federation stops where you get the token and then it is up to you to exchange the token for the actual identity. And this won't work when processed only at the client side.
ADFS 3 does not support the OAuth2 implicit profile, which would be an option, but still you would need to verify the token on the server to avoid session fixation.
You can setup something like AuthorizationServer that supports Oauth2/OpenID Connect implicit profile
http://leastprivilege.com/2013/09/19/adding-oauth2-to-adfs-and-thus-bridging-the-gap-between-modern-applications-and-enterprise-back-ends/
Another option is to use something like Auth0 (Disclaimer: I work for Auth0) which also supports OAuth2/OpenID Connect implciit profile. In that case you wouldn't need ADFS, there is a connector/agent that you install on your network that does not require opening firewalls or anything and it supports implicit profile that is suited to JavaScript apps. This is an example of a single page app tutorial (if you create an account it will tailor the doc with your credentials):
https://docs.auth0.com/singlepageapp-tutorial
I want to ccreate a website that reads one's Gmails headers.
If I use dotNetopenAuth to authenticate -
will I eventually get the user user and password for my applications' needs?
It seems that the answer is no- for security reasons that's why OpenId is for.
But then, I know website that do so. How?
If you use protocols like OpenID or OAuth, you will not have access to the user's userid nor password.
Instead you will receive a unique identifier for the user, which does nothing more than tell you that the trusted provider has validated that the user logged into their provider's account successfully. It is your job to match that unique identifier with your application's user record.
Depending on the provider you use for authentication (Google, Yahoo, MyOpenId, Twitter, etc.), you may request additional information such as the user's email address and name, but you are not guaranteed to get even that.
Under no circumstances will you ever get to see their password, though. If you want that, then you will have to write your application to use your own authentication provider, like the built-in ASP.NET Membership provider.
The point of OpenID is as you say: delegate authentication to another so that you don't have to deal with the password (if there even is one).
Sites that have the user log in with Google, and then gain access to that user's data at Google aren't just using OpenID. They're also using another authorization protocol. Google supports a proprietary one and a more common standard one called OAuth. OpenID and OAuth can be combined such that the user visits Google just once to log in, and then your site gains the access it needs (if the user approves).
If you take a look at the DotNetOpenAuth sample OpenIdRelyingPartyWebForms\loginPlusOAuth.aspx you'll see an example of the user logging into Google, and by doing that giving the site the ability to download the user's Google address book. This can be easily changed to include permissions to do other things (like read email headers) but you'll need to read Google documentation (GData) to learn what scope to use and APIs to call to obtain this information.
Under no circumstances should you be collecting the user's Google password yourself. I suspect that would be a violation of the Google terms of service anyway.