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.
Related
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'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.
The scenario is that a signed in user prepares some material and dispatches it to a number of email addresses. In each email, there's a link to the webpage where they visitors can read about something and leave suggestions.
Since I can't request the visitors to register themselves, the pages to be visited are exposed without any authorization. One requires a valid guid to hit the existing page, though.
My question is if there's a good method to provide authorization of users not signed in. Is the guid token sent out to their email accounts the best protection I can offer, given that they can't be bothered to sign in manually themselves?
I rejected the idea of tracking IP numbers since I can't guarantee that they won't be accessing the website from different locations.
You can use the Shared Access Signature approach. Azure uses that for getting the access for the Storage (with the policies like an expiration time, etc), OneDrive uses similar approach for sharing the files, etc.
I think that (you mentioned Azure) you can even use the Azure Storage SAS mechanisms for that. Without expiration and other policies and just a GUID, i believe, is not ideal solution.
I guess user will open the link in the default browser for most. Than there is a js library Fingerprint which allows to identify user unique browser instance. You can inject this library into target webpage which users will visit from their email client(by clicking on the link). So storing guid plus user fingerprint can provide some simple "authorization".
In general store guid and email where this guid was sent is more generic solution. But not so secured as anyone can steal guid and use for impersonation.
I have an ASP.NET solution that acts as the primary customer portal for my customers. On this website the users can log-in access their important financial information and more. The website uses a custom authentication scheme that checks the user's username (their email) and their password (salt-hashed) against a Users table in a local database.
I am building a new MVC.NET solution that is more of a web-app tool to be used by these same customers for ordering. I want to re-use the sign-on mechanism of the ASP.NET portal to authenticate users. The goal is to save the user from remembering two log-ins or even having to supply the same log-in twice.
What are my options for allowing users who sign on to the ASP.NET solution to then be auto authenticated to the MVC.NET solution? I've listed some ideas below but are these "bad" or is there a more elegant solution? I'd love your input.
Common Cookie I could create a common cookie that the ASP.NET site creates and the MVC.NET site looks for. But is that secure enough?
Token in Query String I could create a token id on the ASP.NET site that is stored in the local database and is then passed in the query string of the link to the MVC.NET site which takes the token id and validates it against the same database.
Hybrid A bit of both?
Other? Got a better idea?
I've recently done something quite similar (the major difference being that it was internal to the company rather than for external customers) using OpenId.
The implementation of OpenId for .NET is called DotNetOpenAuth which should be suitable for your purposes.
It did take me a while to implement; but it works very well, is very flexible, and extremely secure.
More information about openid (from Wikipedia):
OpenID is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service, eliminating the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").2 An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
Oh, and if you'd like further encouragement, Stack Exchange uses it!
#Jmrnet: in response to your last comment:
Perhaps I was unclear. OpenId in and of itself is simply for validating credentials from one location to another (more or less). It's entirely possible to implement as an SSO model where users do nothing different whatsoever - they don't have to choose a provider, or register, or anything like that. For example, in my setup, the user enters a username and password in a web portal, and then clicks a button to launch another site being automatically logged in by OpenId. Nothing different for the user at all! OpenId can be used with any initial authentication model you can think of (note the bolded section in the snippet from wikipedia).
Take a look at SAML:
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
It works using XML and supports encryption.
I am currently implementing two SSO solutions for the same project.
In one, we are interfacing with an external partner and are using SAML.
In the other, we are allowing logged in users access to our Sharepoint and using the "Token in Query String" approach, since we trust Sharepoint to access our membership tables. This approach is much easier than dealing with SAML tokens.
There are many methods you can use, Mansfied described OpenID and RandomUs1r described SAML. Also, you can store relevant information in localStorage or in the session. I believe you should store relevant information with session.
It is not safe to put this in the query string, because if I register and log in, I will see something like UserID=1234 in the URL. If I change that to UserID=1235 and the ID is existent, then I can do some things in the name of the other user. This is called identity theft, which should be prevented by any means possible. So you should never have this kind of info in your URLs. Also, if you store the id of the user, you should obfuscate it somehow. For instance if you store the value in local storage and instead of 1234 you store encrypt(1234, salt), then the consistency of user action will be maintained.
I am writing a small client to sync the outlook calendar on a machine with a user's google calendar. I am using .Net (C#).
I just read about accessing the Google Calendar API using the Google APIs Client Library for .NET and tried some basic stuff.
Now regarding the Authorization, as far as I understood, the new "OAuth 2.0" Authorization requires a "user consent", which means the user is directed to a google page where they must explicitly allow my application access to their calendar.
As if this user interaction is not enough, I as a programmer have to handle "access tokens" or "refresh tokens" and all that stuff.
Now my question is:
Is there really no easier way to have an installed application communicate with the google API to access a user's calendar?
I would like my user to enter his username/password in a "Settings" dialog. His credentials would be stored locally (encrypted of course) and then be used later on every access via google API. I know this can be dangerous and all that however I would like that decision to lie with me.
So, is that possible?
No that is not possible. The entire point of OAuth is the user never gives a 3rd party (you) their username and password. The only thing you get is a token that allows you to connect that the user can revoke at any time. (Also if the user changes his password, you can still use the same saved token and do not need to make the user update their settings).
If you decide to "work around" this by saving the username and pasword and performing the "authorization" yourself you will be in violation with the TOS of the API and will have your application banned by Google (or any OAuth provider if you try it with someone else) for not following the rules.