I have a service that required a session. The reason of that is that the client starts a session, the service query to the database if the username and password is correct and if it is correct, then the service allow to use the service to this session.
I have read that the proxy would be closed after the method call has finished, to release the resources, but I have a doubt. If I close the proxy when the method is finished, the session is closed too, so when I will call another method, I have to query to the database again to check if the credentials are correct before allow to consume the service.
So, wouldn't it be better to keep open the session while the application in the client is open and close the proxy when the client close the application? In this way I keep the connection alive, and the session, but I don't have to get the credentials from the database each time a method is called.
Perhaps I am wrong in the way that I check the credentials to allow or not to the session to use the service.
Thanks.
If your intent is to authenticate user you cane leverage of following option:
Set client's credential to UserName. In this case, before any call gets executed client's username and password are validated against data stored in database. You define custom class deriving from UsernamePasswordValidator where you query DB so as to find out whether caller is allowed to use service. I refer you to this post.
I have readed that the proxy would be closed after the method call has
finished
Not proxy but instance would be destroyed and responsible for that is ReleaseInstanceMode property of OperationBehavior. You would not benefit of such a solution since destroying instance does not deprive user of accessing service. Another instance could be created instead. Of course ReleaseInstanceMode applies to situation when InstanceContextMode is set to PerSession.
Related
When running with Kerberos tickets, I have noticed that every firefox request has a different Authorization line in the HTTP header. I loaded a simple page, then hit the reload button several times and it was never the same. What causes this behavior? I would have thought that the Authorization line would stay constant for the duration of the Kerberos credentials. (Note that I got the credentials via the kinit command before firing up firefox.)
When the authentication method is Basic, then firefox continues to send the same base64 string of 'user:password' every time. This is the behavior I expected.
Any ideas?
mmm it is odd. Any chance that you can post snipptes of the wireshark output. One possibility is that the Service Ticket obtained is not cached and FF gets a service ticket. There have been implementations where a client will get a service but not cache it, instead go and get a service ticket every time needed. Sometimes it is because the process may not have write permissions and it is relatively an inexpensive operation ( a single round trip and symmetric encrypted data)
This is due to various limitations in both HTTP and in how Negotiate-Auth works.
HTTP was originally designed as a stateless protocol, and HTTP's authentication system assumes that model. It was designed to do a full authentication exchange in each request; for example, with Basic, it's enclosing your full credentials in each request. With Negotiate-Auth and SPNEGO, the same thing is true: a brand new GSS-API context is created and a fresh authentication is performed with each request.
Yes, this is very wasteful. But there (currently) isn't any standardized way to authenticate once, establish a session, and then bind all subsequent requests to that session (the way that, say, IMAP, POP, or ssh does). There is some IETF work in this direction, but it's very preliminary.
The ticket is cached; it's not doing that much work each time. But the server and the client go through the whole GSS-API session dance each time.
Using WIF, WCF within a Silverlight client accessing backend WCF services.
The application sign out uses Federation Authentication Module SignOut method which in turn calls Session Authentication Module (SAM) DeleteSessionTokenCookie for the local RP (Relying Party) sign out. A sign out to the the IP (Issuing Party) is subsequently called. All of this functions as expected.
I have come across the following multiple browser scenario relating to shared session that results in a “remote server returned an error not found” issue. If IE's "New Session" is used this is not an issue.
Steps:
Use IE shortcut to open a browser instance 1, navigate to application and login.
Use IE shortcut to open a browser instance 2, navigate to application and login.
Log out of application in browser instance 2.
Perform any operation that requires communication to the server. e.g. Log out of application browser instance 1.
Result: “remote server returned an error not found” exception
Is it possible to detect that the WIF token has been deleted prior to making a WCF call in browser instance 1 and so notify the user. The IdentityModelServiceAuthorizationManager.CheckAccessCore (OperationContext) method is being used to verify service access (authorization) prior to making any WCF service calls. Would it be possible to access and evaluate session token related information at this time? Or is there another approach that can be used?
I'm having trouble getting the user credentials to be delegated over to our Sql Server DB. I'm pretty sure I have my configuration for the WCF set up correctly because everything works on my local IIS where there is only one hop, the problem is getting the double hop to work in a real environment.
The first Error I was getting was a Sql Exception when trying to login with Network Service/anonymous Login. From reading blogs I think the service was falling back to NTLM which cannot perform the double hop.
First question, am I correct in thinking the only way to perform a double hop is with Kerberos?
I switched the config to not allow NTML and got a 'The requirement for mutual authentication was not met by the remote server' error.
I read that I needed to set up a user for delegation. This is where I get lost. The user of the AppPool is NetworkService, what do I need to do to get delegation to work for this? Do I go into the Domain Controller and enable Delegation somehow? What do I need to add to the client config to tell the service about delegation?
I did try adding a new domain user to active directory, enabling delegation for the user, and making the user for my app pool, and added an identity section in the config to speciy this user, but got this error: 'The target principal name is incorrect'.
If possible I would like to keep the network service as my app pool identity. Does anyone know what steps I need to take to get this work?
I am currently following this scenario
Instead of a Windows Forms client, I have an ASP.NET MVC web app.
I am a little worried about the sending of the username and the password
on every call to the Web Service.
That means I will have to carry this information all the time in the session.
Wouldn't that be little security problem ?
Why would you have to carry the credentials all the time in the session? According to the example you're following, they're being set in the proxy (when it's created).
If you're worried about having to cache the credentials for recreating the proxy as needed, then you can cache an instance of ChannelFactory, and then generate new proxies from that instance as needed.
Regardless of what path yout take, the credentials are going to have to be stored somewhere, somehow, unless your application prompts the user for their credentials for every WCF operation.
You can implement WS-Security in your service.
This means you can send user credentials in the header of the message encrypted. Lots of examples out there for this.
hello i have a desktop application that communicate with a wcf service that i building as well
i want to be able to manage the logged on users inside the server without a db (statefull server)
i also want the server to know how to handle 2 client from same computer, whats the simplest way of doing it?
i also have more than 1 service that the client work with (login service and app service)
is there any operationContext Property that can help me?
You can deffinetly manage the logged users inside the server. I have created a personal pattern for dealing with such situations, and it ussually goes like this:
create a client class inside the WCF server that will hold all the needed information about the client.
create 2 methods in the service: logIn, logOut. the login method should be able to gather all the informations about the client that you want to store. Make sure to define properties that can uniquely identify a client instance. When the client conencts to the server it calls the login method, allowing the server to gather and save the information from the client. If using callbacks, this is the place to save the CallBack context object, in the client obejt. You can now save the Client object in the WCF server instance (I use a dictioary). When the client logs out, it calls the log out method and the server removes the entry.
create a KeepAlive method in the server that regularry checks the connected clients to see if they are still connected (in case of network failure or app crash a client may not call the logout method).
I think this is the simplest way (not saying it's the best) to manage clients in the server.
There is no problem with having multiple clients from the same computer (you save the Context when a client logges in) as long as you have a way of uniquely identify clients.
As for your last question, having multiple services should not be a problem. In fact you have the same WCF server with different contracts (and endpoints) for the different services you offer. ALl the contracts reside in the same WCF server instance so they all can access the connected client list.
If you have further questions, I would be happy to answer them.