I have a Silverlight application and in web project i have a login.aspx; which authenticates an user and allows silverlight page to be opened. My problem is i need to disallow a user to copy the direct silverlight url and paste it. The user should follow the sequence all the time i.e Login then SL page.
How to prevent this behaviour.
The basic idea is that each access to the page should check the provided log in details. If the user hasn't logged in, then there will be no log in details and so they will not gain access to the page.
There are several ways to achieve this. You could even implement your own custom authentication system without too much trouble - it just involves checking log in details before displaying any relevant pages. Alternatively, you can read more about the .NET authentication services in the Walkthrough: Using Authentication Service with Silverlight Business Application page on MSDN.
Related
I am creating a .NET class library which will allow local applications to access the accounts of users registered on my website, using an API. I would like the library to handle all authentication of users, so that any app I create an simply call the library, and be returned a token for the API. I'm not sure how to do this authentication.
There are a couple of ways I have considered doing this, however they are not ideal. The first would be to simply create a login form within the library which asks users to enter their login then calls the API. The second method would be to have a webpage where the user logs in and is then given the token which they enter into the app.
The ideal scenario for this situation is that the user does not see their token, and the actual login process is delegated to the website if possible. Both of the above ways lose out on one of those conditions.
The ideal way I would like to do this is inspired from an app I use where if the user is not logged in, they must press a 'Sign In' button, which opens a webpage where they log in. Once they have done so successfully the app automatically detects this and they are signed into the app. The downfall of this solution is that I have no idea how I might do that myself.
Essentially what I'm asking is, is the third solution viable, and how could I do it, or if not are there any better solutions I've overlooked.
FYI the website and API run ASP.NET MVC and WebAPI respectively and the library will use .NET framework.
Edit:
From the comment below it seems likely that you'll want to implement an authentication provider using something like OAuth. The .NET reference libraries can be found here and there's a similar answer already on StackOverflow that may also shed some light.
Welcome to Stack Overflow!
Personally, I would keep the Web API as the authority on authenticating a user and just consume this HTTP endpoint on all platforms (web, desktop, mobile etc) whenever you want to validate a user's credentials.
At a high level the process would be along the lines of:
Have your "clients" (desktop, mobile, web applications) submit HTTP requests to an API route (something like /authenticate) when the user first logs in.
Run your authentication logic
If successful return a token (and cache this this for use in subsequent requests)
Otherwise return a 401 response
Every client will now get a standardised response they can use for determining if they should redirect the user to some protected area, or show them an error message.
This also allows you to design login screens that are native to the platform they're running on (which is a smoother user experience). I wouldn't recommend having a library return a pre-built login page to the user - you'll find that becomes a real pain to maintain!
The third solution you proposed is also a valid way of doing things - but it does have the side effect of redirecting the user's focus away from the application they're using - which you may not want depending on your use case. It's also a bit trickier to implement than just calling the API directly, so unless you have a specific requirement to do it this way I'd not recommend it.
Hopefully this makes some sense. If you are unsure on how to implement cross application authentication then I'd recommend taking a look at some existing answers on Stack Overflow such as:
Basic token checking
OAuth
I'm developing a MVC application that will require a user to be authenticated against an AD. how to create log in page in MVC to create an Intranet Application that automatically authenticates a user against an AD
Why don't you use the Intranet Template provided by Microsoft Visual Studio, which does exactly what you want out of the box?
Your requirement is paradox. Why do you want a login page, which does login a user automatically, while being logged in by visiting the (main-)site automatically, does not require the visitor to do anything at all, because he is already authenticated by entering his credentials at the windows-logon
More information: http://msdn.microsoft.com/en-us/library/gg703322(v=vs.98).aspx
you can use the built in windows authentication feature. the example is in here
if you need mixed authenticated for example you want the user can access from outside using their AD it will involve either two applications or two different pages for authentication types. find the example here
I'm not entirely sure if you actually want a login page that automatically authenticates a user that visits the main site. Maybe your wording is a bit confusing there.
I'll asumme you want your Web-App to be able to authenticate users against AD after having to log in with intranet credentials. If that's the case, you might want to have a look at this article detailing how to set that up using IIS and an ASP.NET app.
If not, please disregard this answer.
I'd like to implement OAuth functionality to allow users of an application i'm building to login via Facebook, Twitter, and possibly Google plus. Every post I've found thus far seems to suggest starting from scratch, creating an MVC 4 'Internet Application' project.
What are the relevant references, code snippets, plugins etc which are required to implement this functionality?
I'm currently using Forms authorization.
Once you have set up Forms Authentication MVC 4 has built in support for users to authenticate themselves with OpenID and OAuth using an open source project called DotNetOpenAuth, it is a very similar system to forms authentication using cookies and redirects.
These services just need to be configured and this takes place during application start-up. Inside the Application_Start() event there is a call AuthConfig.RegisterAuth(), which contains just commented out code to the third party services.
Before you can use these services you need to register your application with most of them. When you register with a third party you will usually be assigned an appId and an appSecret. You need to insert these values into the code where you register with them as a client.
Google is the one provider commented out who doesn’t require any registration so you can just uncomment the line. OAuthWebSecurity.RegisterGoogleClient(); in the AuthConfig.cs file.
When you rebuild the application and go to the login page you will see on the right there is now a Google button you can press to login through the Google service. This button will re-direct the user to Google where they can sign in with their Google account. Once they have signed in Google will ask the user if they happy for your application to have their e-mail address. The user must answer yes, if they decline this they won’t get logged into your application.
Google will then re-direct back to your application sending some cryptographically sealed and signed parameters so OpenAuth can verify that Google did actually authenticate the user. Once the user is successfully authenticated and logged in, they can create an account by clicking the register button they will be presented with.
There is a link in the comments at the top of the AuthConfig.cs file, which goes to a page telling you how to register with the other third party services.
http://go.microsoft.com/fwlink/?LinkID=252166
Regarding your request to do this "without creating an internet application"....
"Internet application" is a type of project that tells Visual Studio what you're using it for. It's not required by any .NET standard, but if you're using Visual Studio then it's a step you need to take. Otherwise VS doesn't know if it should help you build a WinForms app, a Console app, WPF, etc...
The other project type you could use would be a WebSite, however if you intend on leveraging .NET than an Internet Application is a the better choice--it assumes your building a website that will be running .NET code.
Others have mentioned using DotNetOpenAuth to get your site running; I fully support that, but also wanted to mention the Social Bootstrap API project. It achieves a similar result, but does so using ServiceStack.NET. There's a very good chance you won't want to use it, but it's always good to evaluate alternative options--they can help show you the pros/cons of each other.
I have a simple silverlight application hosted on a corporate network. However I want to allow access to this website to few select NT users and restrict the rest. How do I configure it?
Also would such a configuration work for out of browser as well?
you should enable the Integrated windows authentication in the IIS web site or virtual directory configuration. After that in any moment you can take the User.Identity and User.Principal objects and cast them to WindowsIdentity and WindowsPrincipal and check if current user is in a certain role ( aka in a windows group ) or his/her username...
about out of the box I don't know because I have never tried it but you could surely test it once you have a label showing current user name in your SL User Interface, checking if the functionality is the same in the browser or out of browser. Hope this helps...
There are several things you can do.
1) Restrict access to the web services this is calling into - Davide's answer covers this nicely.
2) Restrict access to thw website where the SL app exists, which is easy to do with ASP.NET and the built-in support for Windows Authentication via a MembershipProvider. This way, a user can't even load the HTML page hosting the Silverlight app if they're not in the right role. This would also prevent them from installing the app as Out of Browser, as they can never get to it in the first place.
3) In the OOB mode of the app (when Application.Current.IsRunningOutOfBrowser is true), at startup call into a web service that verifies the user is in the right role - if they're not, the app could simply diplay a "not authorized" visual and not show the real app functionality.
This way, if the user ever was in the role and installed the app OOB, but then lost that permission, they'd still not be able to use the app.
As to implementation of all this, I suggest looking at WCF RIA Services. It has great authentication/authorization support that should simplify implementing this, even if you don't want to use RIA Services for data access for whatever reason (though I recommend that as well, it helps hide a lot of the async complexity of Silverlight data access).
I have a c# class which uses the WindowsIdentity namespace to return details of the current Active Directory user. This is accessible through a web part on SPS and sure enough returns the desired record values specific to that user.
I have a classic ASP application which I would like to have inherit this functionality. After wrapping it up as a COM and registering it to the server, I created a Classic ASP page from which to call and display the details to the browser window.
My problem is that when this page is accessed from an authenticated user on a client machine the only user details it displays is that of the local machine.
How do I therefore alter my code so I can display the details of the user accessing the page from a client machine?
Classic ASP takes us back. :-)
Don't think I've touched it since 2002...
Anything wrong with just looking at Request.ServerVariables("logon_user") in the ASP page?
That should give you the domain\username.
Rather than trying to run the COM-wrapped class under the identity of the end-user (which is the problem you're having), you could just pass the domain\username through to a class to retrieve the account details from AD and then display any needed items from there. That would do away with the need of impersonating to obtain the windows-identity of the current user.
Also check to see what authentication methods the site is running as in IIS.
Right click the website in IIS Manager, Properties --> Directory Security --> Authentication and access control --> Edit...
Make sure Integrated Windows authentication is checked, Enable anonymous access is cleared.