I currently have a JAX-WS Web Service that receives some credentials in the HTTP header. These are used for BASIC authentication.
There is a filter that performs authentication by reading the HTTP headers and checking against the database.
Still, I need the username from within the Web Service in order to perform other service logic related stuff. Is there a way of accessing the HTTP headers from within the Web Service?
Thanks.
The WebServiceContext object does the work for me. It ca be easily injected in my web services as a Resource:
#Resource
private WebServiceContext context;
Related
When i try to invoke a WCF service from an asp.net application (RP) which is authenticated by another asp.net application(IP) , I'm getting an error message with content of Login page (It is trying to reach the login page because it could not authenticate the request).
Identity Provider : _http://localhost/AuthenticatonWS/Login.aspx
Relying party Website : _http://localhost/RPWebsite/Default.aspx
WCF Service : _http://localhost/RPWebsite/Service1.svc
(In my solution I'm calling service1.svc from default.aspx.cs)
I don't want the service to be anonymous. Currently the site (RPWebsite) uses STS and trusts local Identity provider, but in production it can trust any external identity provider thru ADFS.
Can any one guide me how i can pass the token information to the service from aspx page, I did try several examples from internet but i could not get it working.
The problem could very well be that the RPWebsite uses ClaimsAuthorizationModule in <system><httpModules> or <system.webserver><modules> in web.config. This causes any web service call to be redirected to the STS for authentication, as if it were an interactive browser request, as you observed.
Alternatively, this module can be added in the WIF-specific section of web.config, that is, in <microsoft.identityModel><service>, and in this case this module is only used for claims-based WCF web service calls. You add it in the following form: <claimsAuthorizationManager type="MyNamespace.CustomClaimsAuthenticationManager, MyAssembly"/>. (This type must extend ClaimsAuthorizationManager, as described in the WIF documentation page "ClaimsAuthenticationManager, ClaimsAuthorizationManager, and OriginalIssuer".)
Reference: Vittorio Bertocci, "Programming WIF", p. 43.
I think there are several options:
Using Persistent Authentication Cookies that support multiple client sessions. Or support sharing session between your RP and WCF service, so that WCF can re-utilized the authentication cookies issued for RP when RP makes a call to WCF service. To be honest, I have never tried to implement this in action. It is just my theory.
Create an separate authentication service which require no user-interaction (such as entering username/password). And then you have plenty of way to call WCF from your RP:
From your RP, ask the authentication service to issue a token for WCF; attach the token into request header of WCF call (e.g.: Authorization); then call WCF service. This requires a custom HttpModule to accept custom request header containing token at WCF service.
From your RP, you can also store UserName/Password, or an unique user identity claim which could identify the user; attach those information into request header of WCF call (e.g.: Authorization); then call WCF service. This also requires custom HttpModule to accept custom request header at WCF service.
I would recommend the second option, which you could find more useful information and guideline from Dominick Baier's blog.
Just my 2 cents.
I am new to authentication and authorization concepts. I wrote an authenticate method in my wcf servcice. Methods in wcf service will get called only by authenticated users with specific roles. How does the security context automatically get loaded before each request to wcf service?
Since you are looking to reach the authenticated identity, then the following link should be helpful:
http://msdn.microsoft.com/en-us/library/aa347790.aspx
EDIT: If you want to automate this, you should write a wrapper for your service host (i.e: a class that inherits from ServiceHost) to encapsulate that inside your service host rather than having to write it over and over again.
I want to port an existing ASP.NET Web Service to WCF so the resulting Web Service (1) is RESTful, (2) uses JSON as its request/response format, (3) has a custom authentication mechanism.
After a lot of googling, random coding, and wanting to hit my head against the wall, I found that...
A webHttpBinding has to be used to make the Web Service RESTful. But...
webHttpBinding does not support HTTPS hosts.
webHttpBinding does not support UserName authentication.
webHttpBinding does not even support message security.
An endpoint behavior with <enableWebScript/> has to be used to support ASP.NET AJAX. But...
What is "ASP.NET" AJAX?
What if I want to consume the Web Service using "regular" AJAX?
And, most importantly...
Can WCF do what I want to do in first place?
If not, what other platforms could I use?
I've written WCF service that does both SOAP and REST with XML and JSON, and custom auth. I've pushed the custom authentication into HTTP module, which does basic auth over https. See Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008 and WCF POX, JSON and SOAP Coexist.
In the setup you describe, the web servier (i.e. IIS) will be responsible for encryption (HTTPS) and authentication (e.g. basic authentiction). IIS can be extended with a custom authentication mechanism (just google for "IIS module handler").
It's a bit strange that it has to be delegated to IIS and is not part of WCF. But it's no problem at all.
I'm using WCF to build some REST-based services. These services will be connected to via client-side Silverlight and Java applications. I would like to know some information about the requester. My question is, what class exposes requester information in WCF and how do I access it?
I know in ASP.NET I can use HttpRequest. I can even get more details via the HttpRequest.Browser property.
I just read about this:
WebOperationContext.Current.IncomingRequest
where you should info about the clinet and the http request headers.
Hope it helps.
Writing a suite of IIS hosted WCF webservices (both GET and POST), and I need to be able to read a cookie for an authentication token so I know the user has been auth'd previously.
Will HttpContext.Current.Cookies give me what I need or is there something cleaner and more appropriate for a WCF web service with WebGet and WebInvoke attributes?
string cookieHeader = WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.Cookie];
works for me