I'm consuming a lot of WCF Services from a Silverlight application in a totally disconnected-way.
I want to ensure that I know the user who is calling every service and I don't know if there is a "standar way".
I've thought of a Login method to get a Token and then pass the username and its token in every call to ensure he/she is logged and has permissions to execute it.
Is there any "almost-done" way with ASP.NET authorization in my own SQL Server? Or I can only use its tables but I'll have to do it "manually"???
Thanks in advance!!!
It sounds like using ASP.NET Membership might be a good fit for you. There's two approaches you an use with this. The first is to use the default membership tables as generated by aspnet_regiis. This option has the advantage of being basically done for you. In this case, all you'd need to do is run the aspnet_regiis tool, then add the necessary portions to the Web.config for your WCF service as described here. Then, when calling the service you need to set credentials for your binding as described here - specifically the portion about setting ClientCredential for your binding when consuming the service.
The other option is to write your own custom membership provider as described here. This allows you to do whatever you want behind the scenes in terms of storing and managing your users, rather than using the pre-built ASP.NET mechanisms. This is a good approach if you're mating with an existing user base or want to have more control over how things are implemented.
Also, keep in mind that ASP.NET Membership isn't your only option for securing your WCF service. Spend some time reading up on your options, which include:
Windows Authentication and Windows Authorization via transport level security on basicHttpBinding
Windows Authentication and Windows Authorization via message level security on wsHttpBinding
UsernamePasswordToken Authentication with ASP.NET Membership and ASP.NET Role Authorization via message level security on wsHttpBinding
UsernamePasswordToken Authentication with custom validator via message level security on wsHttpBinding
Authorization using a custom Authorization Policy
Impersonation using Windows credentials
That list comes from this blog post, which is a good place for you to start exploring your options. Reading up on them will give you the opportunity to learn the strengths, weaknesses, and features of each so that you can choose the one that best suits your purposes. You can also begin with the MSDN articles on WCF security here.
In summary, yes there is an "almost-done" way to do it with ASP.NET Membership, and it shouldn't be too hard to implement, but take some time to explore your other options as well before just diving in with one, because they all have trade-offs and you don't want to have to re-implement it in the future if you decide the approach you chose is a bad fit.
One way to do this is if you can impersonate all users for that You need to add following in your service behaviour
<serviceAuthorization impersonateCallerForAllOperations="true" />
more details here http://msdn.microsoft.com/en-us/library/ms731090.aspx
and if you want to know the user then inside your service methods you can use
System.Threading.Thread.CurrentPrincipal.Identity.Name
to find the user name who is using your services
Edit:
You can use membership api details here
http://msdn.microsoft.com/en-us/library/ms731049.aspx
http://blogs.msdn.com/b/pedram/archive/2007/10/05/wcf-authentication-custom-username-and-password-validator.aspx
http://social.msdn.microsoft.com/forums/en-US/asmxandxml/thread/8a679fb2-e67e-44a9-b491-eb95d5144068
Related
I have some questions regarding Identityserver4 in the following context:
I have a number of domains (domainA, domainB, domainC ect.) and I’d like all of them to use Identityserver4 for authentication, but I’d like only one implementation of Identityserver4 (with asp.net identity and EF) and have the all domains use this implementation as clients. All domains is in a hosted environment with MS SQL as database, if that has any relevance.
Question 1:
Can IdentityServer4 run in a subfolder/area of domainA, and if so what are the necessary steps for getting this to work, e.g. the endpoints shown in the .well-known endpoint?
Question2:
What are the pitfalls, if any, in hosting Identityserver4 in a subfolder/area under domainA, and also having domainA use Identityserver for authenticating users for the rest of the site, and how to avoid the pitfalls if there are any?
The authorization part that permits one user to do this and not that, and the opposite for another user is not the concern of Identityserver4, but the respective domains/sites own responsibility as I understand what I can find online. In order to make use of roles and roleclaims in asp.net identity core 2 in each domain/site there has to be a user in that domain/site, that has a reference to a user in Identityserver4 in order for the domain to use Identityserver4 for authentication.
Question 3:
How do I avoid that the user must register both on the domain and in Identityserver4, one registration would be preferable and have the other made behind the scenes along with the reference?
I hope someone can provide the answers to one or all of my questions. Links to relevant blogs etc. are welcome, but I have scoured the web to find useful answers without any luck – hopefully some of you have better search engine skills than me.
Q1
Yes you can. IdentityServer is OWIN hosted environment, thus it will be working as a middleware for your domainA, if you set it up so. Having a public endpoint entirely depends on your domainA.
Q2
The possible problem you will possibly encounter would be performance issues. your domainA is going to receive requests from domainB and domainC including, of course, domainA itself. And IdentityServer's checks-up such as authentications, validations, issuing tokens could be obviously time consuming jobs compared to the plain HTTP requests.
While the middleware is doing its job, the performance will hit slightly lower rate then domanB and domainC. But this is a necessary, unavoidable backfire because you added one another layer in your HTTP windows to deal with the authentication / authorization / validation issues on your service endpoints.
You may want to scale out your IdentityServer if the traffic gets much more huger then you expected and you feel your authorization server is dragging the whole services down. I recommend you to perform some stress tests beforehand and compare the performance differences between the services using the identity service and the services using none of that.
Q3
This could be highly opinionated answer. But as you mentioned ASP.NET Identity and EF I think you already know the answer. It seems that you're going to manage the token and identity information in your own hosted DBMS. Then consider it done with the possible duplicated registrations. Your DBMS and your implementation for storing and fetching such data will do it for you as long as you've done it right.
If you're not going to use DBMS for the identity and token data, and use a cache or a file system instead, then you will have to pour some efforts into the implementation in order to guarantee concurrency on the transactions for such data.
I am going to be developing an application for work, and I am trying to decide whether to use Silverlight Business App or Asp.Net Web App. My manager is concerned about the performance and download time it would take if I created the entire application as a Silverlight app, with authentication. I have been playing around with some tutorials over the last week trying to get a perspective on my situation and have come up with a design question I need to ask those that are more experienced than me.
Is it possible to use a Asp.Net application and just embed a silverlight application in one of the pages that will be used inside a folder that is configured with the roles authorization? And if so, would it be possible to get user credentials from the client silverlight app without passing them through the initParams.
I understand that I can set the authentication to "useCookies", so I was thinking I would be able to get the cookie on the client and hopefully get a property verifying if the user is authenticated.
Also, would this be a risky practice? Thanks for any advice and direction.
There are a few approaches you could take. While I know you don't want to expose the credential in init params, you could generate a "ticket" (claims-based authentication) for the credential, and include the ticket (for example, a GUID) in the init params. When the Silverlight application launches, it would consume the ticket, possibly validating it via a secured web service call, and the ticket would no longer be valid so even if someone spoofed it or viewed the source, it couldn't be used.
Quite a bit depends on your architecture. For example, if you are using the roles-based authentication, and most of the business logic and/or decision making is based on web service calls, the web services can use HttpContext.Current.Identity to validate the user. Even if someone opens the Silverlight application, any service calls would fail unless they were appropriately authenticated. Otherwise, I would either go with passing a ticket so Silverlight trustst the user is valid (you can create a service that accepts the Guid and returns the role information) or have the user log in from Silverlight (you have a service facing in front of the authentication mechanism and then return a ticket and/or role information).
It gets even more interesting if you decide to use WCF RIA, check out these examples for baked-in authentication:
http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2661
1.) It's absolutely possible to embed a Silverlight xap on an ASP.NET page.
2.) As far as credentials, using cookies could work, or you could pass in a token over initparams and validate that token via a web service to see if the user is valid
It's always a risk passing credentials around, especially when it's running on a clients computer. That said, Silverlight buys you a lot, so don't let the challenge of authentication hold you back.
I have googled a bit for how I should handle security in a web service application when the application is basically the data repository for a Silverlight application, but have gotten inconclusive results.
The Silverlight application is not supposed to have its own user authentication, since it will be reachable only through a web application that the user have already authenticated to get into.
As such, I was thinking I could simply add a parameter to the SL application that is a cookie-type value, with a certain lifetime, linked to the user in the database. The SL application would then have to pass this value alongside other parameters to the web services. Since the web service is hopefully going to be a generic web service endpoint, few methods, adding an extra parameter at this level will not be a problem.
But, am I supposed to roll this system on my own? It sounds to me as this isn't exactly new features that nobody has considered before, so what are my options?
First of all use SSL for the service. Otherwise users will be able to capture all the parameters passed to the service. It's still possible to see it in case of https but it will be a little bit more difficult.
Also, consider using Message Inspector for adding custom headers to the messages which you will validate on the server. This way you will not need to add extra parameters.
I have a Silverlight application that needs to retrieve some data from my database. This data is sensitive. Because of this, I only want my Silverlight application to be able to access the data. How do I ensure that only my applications can access the services that expose this data? Is there a way that I can validate a client attempting to retrieve the data?
Thank you!
These might be of interest:
Using ASP.NET Secure Services and Applications Services
Build Line-Of-Business Enterprise Apps With Silverlight, Part 2
MS Whitepaper: Security Guidance for Writing and Deploying Silverlight Applications
Well, everything your SL application does could be spoofed. So direct answer is NO, you cannot ensure that only your application will access to the data.
But there are number of options. For example you can implement authorization and then authenticate your user. In this way you can ensure that only users you trust access to the data.
Another option is to make spoofing harder. For example you can include sort of "secrete" token to all your requests. So other application will need to steal this token. This harder to achieve.
I think this question is more pertaining into implementing a web service or wcf service with authentication and authorization. If your service takes care of it, then you can be ensured about your data. Your silvelight app is just calling the service.
Whoever download the xap can decompress and reverse engineer your code, so your best bet is to build a web service as others suggested. Silverlight Ria ships with a full blown authentication membership that you can leverage.
There are a number of questiosn on StackOverflow that ALMOST hit this topic head on, but they are either for other technologies, reference obsolets information or don;t supply an answer that I can suss out. So pardon the almost duplication :)
I have a working ADO.NET Data Service, and a WPF client that hits it. Now that they are working fine I want to add authentication / security to the system. My understanding of the steps so far is...
Turn on forms authentication and configure it on the server (I have an existing asp.net membership service DB for other aspects of this app, so that isnt a problem) so that it is required for the service URL
In WCF apply for and recieve a forms authentication "ticket" as part of a login routine
Add that "ticket" to the headers of the ADO.NET service calls in WPF
Profit!
All well and good - but does anyone have a line on a soup to nuts code sample, using the modern releases of these technologies?
Thanks!
I have an example of doing this from Silverlight on my blog.
Check it out here : Forms Authentication and ADO.NET Data Services
You should be able to adapt this to a WPF application with minor code changes.