I am working on Asp.Net MVC 5. When i click a link (placed in another website) I navigate to UserDetails.cshtml page. Basically that 3rd party site is passing the UserName & Password to my site & using that I authorize & display further user info.
It's fine but the Url is looking like this
localhost:8080//Admin/UserDetails/UserName/PWD.
I don't want to show the UserName & Password in URL i.e URL should look something like :
localhost:8080//Admin/UserDetails/
One possible solution could be rewrite the URL in IIS (http://www.hanselman.com/blog/ASPNETMVCAndTheNewIIS7RewriteModule.aspx)
But I believe there is an easier way to handle this by using the routing mechanism of MVC.
Please help me to figure out the same.
EDIT :
As many of you are confused why I am not doing a Form Post here, let me re-frame my question. I have no control over the third party application, so I cant request them to do a form Post to my MVC application. Again the 3rd party application is a Oracle Reporting application (OBI), so doing a POST from that application might not be feasible too...
Let me reverse engineer your requirements from your question:
I want to have an URI that when invoked will give access to a secured section of my website. This URI must be clicked by visitors of a third-party site, whom I give that URI to. I want to hide the credentials from the URI.
You cannot do this, the requirements are conflicting. You cannot hand out URIs that will authenticate anyone who fires a request to that URI.
You could do something with a token (like http://your-site/auth/$token), but then still, anyone with access to that URI can use it to authenticate themselves, or simply put it up on their own website.
If you have data you want to expose to a third-party site, let that site perform an HTTP request (with tokens, usernames, headers or whatever you want to use to authenticate) in the background to your site, and display the response in their site. Then the visitor won't see that traffic, can't share the URI and all will be secure.
No. No. NO. Like seriously, NO. Any sensitive information should be sent via a post body over a secure connection (HTTPS). You can't "hide" information in a GET request, because it's all part of the URI, or the location of a particular resource. If you remove a portion, it's an entirely different location.
UPDATE
I find it extremely hard to believe that any third-party application that needs to authenticate via HTTP and isn't designed by a chimp with a typewriter, wouldn't support a secure method to do so, especially if it's an Oracle application. I'm not familiar with this particular app, but, and no offense meant here, but I would more easily believe that you've missed something in the documentation or simply haven't found the right way to do it yet before I'd believe you have to send clear-text credentials over GET.
Regardless, as I said previously, there's no way to hide information in a GET request. All data in a GET is part of the URL, and therefore is plainly visible in the browser location bar or whatever. Unfortunately, I have no advice for you other than to look closer at the documentation, even reach out to Oracle if you have to. Whether by post or something like OAuth, there almost has to be another way.
Related
I have an ASP .Net MVC5 application using Azure AD Authentication. Whenever I enter URL, it takes me for authentication (if not done already) using a URL of this sort.
https://login.microsoftonline.com/[tenantID]/oauth2/v2.0/authorize?
There are 3 questions
Can I say its using OAuth2 ?
If someone enters a url for a page e.g. https://mydomain/Category/View/1, then it goes for auth (which is alright), but then post successful authentication, it should redirect me to the originally requested URL but currently its taking me to the root URL https://mydomain . But subsequent ones, work fine once authenticated.
Currently the auth happens every 1 hr I believe..how can I extend it to every 4 hrs ?
Will be helpful to see your suggestions.
Cheers.
According to your description of point 2, would you like to achieve that, visiting a url -> direct to login page -> redirect to that url? If so, I think this document can help you.
In my opinion, if I wanna a demo app or app just for simple test, just add all possible url to the redirect configuration form. If I need to do an formal app or I need to make it easy to maintain, I use the idea in the above document. I think the centeral thought is creating a specific place to control url redirecting, including judgment, and only need to add this specific url to the redirect configuration in azure portal. If you wanna a sample, may this document will help you.
To point 3, emmm perhaps you can search for some key words like 'azure ad authentication set token lifetime policy', I found several powershell scripts but I haven't tested. If you haven't got the result I will do some test on it next Monday.
I have an app, client side, that uses auth0 for accessing the different API's on the server. But now I want to add another app, a single page app, I'm going to use VueJs, and this app would be open "ideally" w/o a user having to sign in, it's like a demo with reduced functionality, I just want to check that the user is not a robot basically, so I don't expose my API in those cases.
My ideas so far:
- Somehow use recaptcha and auth0 altogether.
- Then have a new server that would validate that the calls are made only to allowed endpoints (this is not of my interest in the question), so that even if somehow the auth is vulnerated it doesn't leave the real server open to all type of calls.
- Pass the call to the server along with the bearer token, just as if I was doing it with my other old client app.
Is this viable? Now I'm forcing the user to validate, this is more a thing about UX (User-experience), but I'd like a way to avoid that. I'm aware that just with auth0 I can't do this see this post from Auth0, so I was expecting a mix between what I mentioned.
EDIT:
I'm sticking to validating in both cases, but I'm still interested to get opinions over this as future references.
At the end, with the very concept of how auth0 works that idea is not possible, so my approach was the following:
Give a temporary authenticated (auth 0) visitor a token which has restricted access level, then pass the request to a new middle server, the idea is to encrypt the real ids so the frontend thinks it's requesting project A123456etc, when indeed it's going to get decrypted in the middle server to project 456y-etc and given a whitelist it will decide to pass the request along with the token to the final server, the final server has measures to reduce xss and Ddos threats.
Anyway, if there's a better resolve to it I will change the accepted answer.
You could do a mix of using recaptcha for the open public, then on the server side analyse the incoming user request (you can already try to get a human made digital fingerprint just to differentiate with a robot-generated one) and the server (more a middle server) makes the call to you API (and this server has limited surface access)
What we normally do in these situations (if I got your issue correctly) is to create two different endpoints, one working with the token and another one receiving the Recaptcha token and validating it with Google servers.
Both endpoints end up calling the same code but this way you can add extra functionality in a layer in the 'public' endpoint to ensure that you are asking only for public features (if that cannot be granted just modifying the interface).
Why do I continuously receive "The provided value for the input parameter 'redirect_uri' is not valid."?
My site is hosted in Azure. I'm trying to Login via the Microsoft sign-in button. I haven't really made many changes from the default ASP.Net MVC out-of-the-box template. All I've really changed was to uncomment the app.UseMicrosoftAccountAuthentication line and add the clientId and clientSecret.
Do I have the Redirect URL set up incorrectly?
Site: http://mysite.azurewebsites.net
Redirect URL: http://mysite.azurewebsites.net/
I read somewhere that you need to specify a Redirect URL in the form of http://www.mysite.azurewebsites.net. Can anyone confirm or deny that? I do not need the www in my current set up.
The error I consistently receive is:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The provided value for the input parameter 'redirect_uri' is not valid. The expected value is 'https://login.live.com/oauth20_desktop.srf' or a URL which matches the redirect URI registered for this client application.&state=SomeLongPossiblyEncryptedString
This message is displayed on the page returned after an attempt to login:
Microsoft Account
We're unable to complete your request
Microsoft account is experiencing technical problems. Please try again later.
3/26/2014 Update: No luck so far, here's some screen shots of my settings in case it helps.
Basic Information
API Settings
Is this a problem on Microsoft's side or am I doing something wrong?
From the default MVC what works for me (just tested about 5 minutes ago) for the redirect URL is
http://testcrap.azurewebsites.net/signin-microsoft
All the documentation I've found says to use
http://testcrap.azurewebsites.net/login/microsoftaccount
But that doesn't work for me...
signin-microsoft does
OR if that doesn't work then use something like firebug to see what the request to the oauth provider looks like and then whatever the redirecturi is inside of that request is what you need to use..
For web application you need to set the redirect url in the Live Connect Developer Center.
In API Settings->Redirect URLs you must set:
http://www.yourdomain.com/signin-microsoft
Hope it's helpful :)
You need to provide the redirect url in the Live Connect Developer Center. I've attached a screenshot. This is part of the application validation to prevent malicious applications.
It seems Microsoft change the url again. This what works for me
.auth/login/microsoftaccount/callback
My redirect url is
https://yyyyyyyy.azurewebsites.net/.auth/login/microsoftaccount/callback
To get this url, use Fiddler or any http debug tool and look for request to login.live.com. The redirect_url is in the query string.
https://login.live.com/oauth20_authorize.srf?client_id=00000000551716B9&redirect_uri=https%3A%2F%2Fyyyyyyyyyy.azurewebsites.net%2F.auth%2Flogin%2Fmicrosoftaccount%2Fcallback&response_type=code&scope=wl.basic+wl.offline_access+wl.signin+wl.birthday+wl.calendars+wl.calendars_update+wl.contacts_birthday+wl.contacts_create+wl.contacts_calendars+wl.contacts_photos+wl.contacts_skydrive+wl.emails+wl.events_create&state=nonce%3Dfe7e6b678b8844f48f079cceadf1f426_20151206145117%26redir%3D%2F
Since I need 3 more reputation points to write a comment to your post I have to ask it here. Sorry about that.
Are you getting this error while trying it out on the real domain or while testing it from your localhost?
If the second is the case you need to setup a DNS entry for a dummy hostname in your local host file that points to 127.0.0.1 and use that dummy name when registering with live. Furthermore it needs IIS, not IIS Express.
Not sure if it is a clean way nor if it is complete, but it is the furthest I got when trying out the new ASP.NET Identitiy Provider. Sadly there is only a example in the official documentation which shows how to use it with google...
I, too, would appreciate a clean answer to this.
Redirect URIs are "SSL sensitive" and you probably always want the SSL version.
I have to implement a web site (MVC4/Single Page Application + knockout + Web.API) and I've been reading tons of articles and forums but I still can't figure out about some points in security/authentication and the way to go forward when securing the login page and the Web.API.
The site will run totally under SSL. Once the user logs on the first time, he/she will get an email with a link to confirm the register process. Password and a “salt” value will be stored encrypted in database, with no possibility to get password decrypted back. The API will be used just for this application.
I have some questions that I need to answer before to go any further:
Which method will be the best for my application in terms of security: Basic/ SimpleMembership? Any other possibilities?
The object Principal/IPrincipal is to be used just with Basic Authentication?
As far as I know, if I use SimpleMembership, because of the use of cookies, is this not breaking the RESTful paradigm? So if I build a REST Web.API, shouldn't I avoid to use SimpleMembership?
I was checking ThinkTecture.IdentityModel, with tokens. Is this a type of authentication like Basic, or Forms, or Auth, or it's something that can be added to the other authentication types?
Thank you.
Most likely this question will be closed as too localized. Even then, I will put in a few pointers. This is not an answer, but the comments section would be too small for this.
What method and how you authenticate is totally up to your subsystem. There is no one way that will work the best for everyone. A SPA is no different that any other application. You still will be giving access to certain resources based on authentication. That could be APIs, with a custom Authorization attribute, could be a header value, token based, who knows! Whatever you think is best.
I suggest you read more on this to understand how this works.
Use of cookies in no way states that it breaks REST. You will find ton of articles on this specific item itself. Cookies will be passed with your request, just the way you pass any specific information that the server needs in order for it to give you data. If sending cookies breaks REST, then sending parameters to your API should break REST too!
Now, a very common approach (and by no means the ONE AND ALL approach), is the use of a token based system for SPA. The reason though many, the easiest to explain would be that, your services (Web API or whatever) could be hosted separately and your client is working as CORS client. In which case, you authenticate in whatever form you choose, create a secure token and send it back to the client and every resource that needs an authenticated user, is checked against the token. The token will be sent as part of your header with every request. No token would result in a simple 401 (Unauthorized) or a invalid token could result in a 403 (Forbidden).
No one says an SPA needs to be all static HTML, with data binding, it could as well be your MVC site returning partials being loaded (something I have done in the past). As far as working with just HTML and JS (Durandal specifically), there are ways to secure even the client app. Ultimately, lock down the data from the server and route the client to the login screen the moment you receive a 401/403.
If your concern is more in the terms of XSS or request forging, there are ways to prevent that even with just HTML and JS (though not as easy as dropping anti-forgery token with MVC).
My two cents.
If you do "direct" authentication - meaning you can validate the passwords directly - you can use Basic Authentication.
I wrote about it here:
http://leastprivilege.com/2013/04/22/web-api-security-basic-authentication-with-thinktecture-identitymodel-authenticationhandler/
In addition you can consider using session tokens to get rid of the password on the client:
http://leastprivilege.com/2012/06/19/session-token-support-for-asp-net-web-api/
I am attempting to construct a web app in which the back end is a complete RESTful web service. I.e. the models (business logic) would be completely accessible via HTTP. For example:
GET /api/users/
GET /api/users/1
POST /api/users
PUT /api/users/1
DELETE /api/users/1
Whats the proper way to provide more methods that aren't CRUD (verbs/actions)? Is this considered more of a RPC-api domain? How would one properly design the RPC api to run on top of the RESTful api?
For example, how would I elegantly implement a forgot password method for a user.
POST (?) /api/users/1/forgot
The application (Controllers/View) would then use a https requests (HMVC like) to access the models and methods. What would be the best for authentication? OAuth, Basic Auth over HTTPs?
Although this is "best practice" for scalability later on, am I over engineering this task? Is it best to just follow the typical MVC model and provide a very basic API?
This question has been mostly inspired by ASP.NET's MVC 4 (WebAPI) and a NodeJS module https://github.com/marak/webservice.js
Thanks in advance
I recently started learning REST, and when developing a new web service I think you're doing the right thing to consider it.
You are correct in your assumptions about the custom verbs. REST acknowledges that some actions need to be handled in a different way, and custom verbs don't violate the requirements. You should use POST when communicating with the server, but the verbs are normally written in imperative. Instead of forgot, I'd probably use remind or something similar. I.e., you should give instructions on what to do, rather than describe what happened without clearly indicating what you expect as a result.
Furthermore, the preferred way to construct the service is to include api into the domain name, and drop it from the path. I'd write your particular example like this:
POST /users/1/remind HTTP/1.1
Host: api.myservice.example.com
Session handling in REST is a bit tricky. The cleanest way of doing it would probably be to authenticate with username and password on every single request, using Basic access authentication. However, I believe that it's rarely done like that. You should read this question (and its accepted answer): OAuth's tokens and sessions in REST
EDIT: I'd also drop the trailing forward slash in the GET request in your example. If the service is truly RESTful, then the resource is not supposed to be accessibly from both /users/ and /users. A particular resource should have one and only one URL pointing to it. A URL with a trailing slash is actually distinct from one without. REST promotes dropping it, and a RESTful web service should not accept both (which in the case of GET means responding with 200 OK), although it may redirect from one to the other. Otherwise, it might lead to confusion about the proper URL, duplicate caching, weeping and gnashing of teeth. :)
EDIT 2: In RESTful Web Services by Richardson & Ruby you're discouraged from putting the new verb in the path. Instead, you could append something like ?_method=remind. It's up to you which one you choose, but please remember that you're not supposed to handle these requests with GET, regardless of what you choose. A GET must not change the resource, and should not cause side effects if the user browses back and forth in the history. Otherwise, you might end up resending the password several times. Use POST instead.