I am working with WCF Webhttp services. I have created a bunch of services and all that remains is to put in user authentication...
Questions
Keeping with the rest architecture style, should I authenticate each service call against the user db.
If so, I should just do authentication by supplying the credentials and password each time the service is called and make it secure with SSL. Basically, each webget/webinvoke function should contain the user credentials as parameters and I authenticate each call. Is this right? This seems rather inefficient.
Using session key somehow seems wrong but any pointers as to how to use Session in WCF Webhttp?
I am not working with ASP .net membership (will be looking into it soon) since I was working with Mysql and have my own registration/user database created. Should I be looking at that? Can I use a wcf authentication service along with wcf webhttp services?
Any literature on handling authentication in WCF webhttp services would be greatly helpful.
Many thanks
You can check Chapter 8 of RESTful .NET book (Amazon, Google books)
You will authenticate only the first call from the user, any subsequent calls will use the context of the authenticated user. There are several options how you can use SSL(TLS), like always or just when you send username/password.
I am not sure where exactly and how you store the authentication token (like in Session or similar type).
You don't need to use ASP.NET membership provider, in fact you may not use any membership provider at all, just use other authentication models. Usually, there will be only one authentication model per service, like you get the credentials, check them against persisted storage, if valid you set the security token and that token is used for all the next calls for a limited amount of time.
Related
Good day. I've looked all over for an example of how to do this, and while I have found all sorts of useful info on how to implement bits of it, the overall solution still eludes me.
I have a 3-tier web-based application (Presentation tier is Web Forms, business/DAL tier is a WCF web service, DB is Oracle) for which I want to implement an Authorization/Authentication mechanism.
My thought was to use the Enterprise Library Securty block to generate a token in the WCF service (and cache it there), and send the token id back to the web-app server. The token id would be sent back to the client browser (via a cookie) and then all subsequent requests back to the WCF service I would pass this token id in the header of the request message. I would then use some of the WCF extensibility interfaces to check for authentication by looking for the id in the cache. I was also going to cache the roles (I'm just using simple role based access) with the token so that I had in-memory access to the roles list for the user and I could avoid a DB round-trip for every access check.
Does this part make sense as to the right way to go? If so, here is the second part.
Now my problem is how to manage role access and session management from the webserver hosting the presentation tier. I'm managing the roles from the business layer, but I also need access to them in the presentation layer because I also wanted to use role-based access to each page via the web.configs. How do I do this? should I also pass the roles back to this layer? There is something smelly about both the service and the webapp having to store versions of this rolelist.
Any assistance would be much appreciated!
I'm using Message/Username/Custom MembershipProvider for my WCF service authentication.
by default, WCF authenticates every call from the client.
My Custom MembershipProvider access database for checking username/password.
so for each call from the client the service has to access database for authentication, and this might have performance implications as the number of calls increase.
Is there a default way to cache this authentication information(perhaps by creating a ticket and using that ticket for further authentication as in ASP.NET)?
You absolutely could use ASP.NET Forms Auth for WCF calls, keeping the token as a cookie that's passed with every request.
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.
(I tried searching, but couldn't find any truly helpful links.)
We are implementing a set of WCF services. What I would like to do in these services is have the clients (which will be trusted application servers) be able to pass a token of some sort to the web service to authenticate. I do not want to be required to pass username/password on the initial or subsequent requests (because in some cases the calling application server may not have the password). Windows and Kerberos are not usable in our specific circumstance.
I had thought to just create a simple custom UserNameSecurityTokenAuthenticator class and modify it so that if the password is empty, it takes userName as the string-encoded token value (obviously checking the token itself to verify that it's valid at that point), but if the password is not empty, forwarding on the username/password to a MembershipProvider for checking. Basically I'd like to overload the username/password authentication to provide for token passing as well.
Is this possible? Can I simply plug in a token authenticator like this, or is there some other simple way to "intercept" requests like this (and update the actual username value from the decrypted token)?
Or is there some other incredibly simple way to allow the client to pass a custom token and have the server accept it that I'm just missing?
If it's a fairly controlled environment and not too many clients involved, then I'd try to set up something along the lines of the B2B scenario securing the transport link using certificates on both ends.
Certificates are not bound to Windows or an AD domain, and setting them up is a one-time job.
Read more about that WCF security scenario:
MSDN: Transport Security with Certificate Authentication
Fundamentals of WCF Security: Business Partner Applications
. WCF Security How-To's
I have multiple NET.TCP services that provide access to my apps bussiness logic layer. I want to authenticate clients with username & password, within all the services, from one dedicated authentication service.
I have thinked that I can generate a custom authentication ticket when the authentication service logons the user and send it to other services. However when talking about security I prefer to use builtin implementations that have been already tested.
Is there a more WCF way to do this? Should I ever try this, or share the authentication logic and authenticate every service?
Thanks in advance
Yes, the (new) WCF way to do this is to use a (or implement your own) security token service based on the windows identity foundation framework.