I have followed all the steps mentioned in the following link to implement oAuth authentication for connecting to VSO:
https://www.visualstudio.com/en-us/integrate/get-started/auth/oauth
It involves creating a azure web site and the token in returned to it which is used for further processing.
My requirement is to create a service which will connect to VSO using oAuth authentication and fetch/create the work items.
I want to know how to configure the call back url in case of using a service.
Firstly, please take note that: Right now, it is only supported to register web application, it is impossible to register a WCF service project.
If you would like to register a web application and would like to get the call back URL, please check my reply in this link for the detailed steps: callbackurl while connecting to vso using oAuth
Related
I'm looking for a way to expose my customer's WCF Services as REST Services (and create all the security stack to support claims / oauth authentication and authorization)
I'm working on 2 different approach to do so:
Create a new REST Service which will act as a proxy to
expose my WCF Service as REST Services (11 services / 130 web methods to
migrate...) and secure it using an IP STS / RS STS
Use a existing product like Apigee which will do all those job for me and even more feature than initially planned.
I'm trying to play with Apigee first, but I'm facing an issue while creating the API Proxy.
I've deployed a simple WCF Service (with only 2 methods) on a Windows Azure VM exposed in basicHttp (which works as expected - means I test it in a Console app successfully, even when the client app is located outside my Azure's VM -).
Problem comes when I follow the Apigee workflow to expose it as a REST Service. I try to fetch service's wsdl on Apigee portal and got following error:
Error: Cannot invoke method getOperation() on null object
Does someone know where the issue come from ? I don't have much information from Apigee portal.
I already validate my wsdl through http://www.wsdl-analyzer.com/ but everything looks fine...
Meantime, Amazone webservice works fine on Apigee and generate the REST Service so problem seems to come from my service's WSDL
This bug has been fixed and will be included in the next release (R24.4). If you still have any problems with the new release, please let us know.
I recently got a similar error in the most recent version of Apigee (Version 141029).
The error: "Fetch WSDL Error: Cannot invoke method startsWith() on null object".
The fix was to rename my local file from "somename.xml" to "somename.wsdl".
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.
My server side contains WCF4 REST services and I'm going to add RIA services for my future SL4 application. Currently I'm doing Basic authentication like this:
var auth = HttpContext.Current.Request.Headers.GetValues("Authorization");
And so on.. You get the idea.. I call this on every request. If header not present or I can't validate UN/Password - I do this:
outgoingResponse.Headers.Add("WWW-Authenticate: Basic realm=\"Secure Area\"");
That got me by so far but I'm refactoring my server side. Implementing IoC for linked services. Created custom ServiceHost, ServiceHostFactory, InstanceProvider and all is well.
Now I need to figure how to properly handle authentication and authorization with WCF so I don't have to manually inspect headers. I do have my custom MembershipProvider so there have to be some method that get's UN/PW to process.
Any pointers? I looked at http://www.codeproject.com/KB/WCF/BasicAuthWCFRest.aspx but it uses RequestInterceptor and it is not available in WCF4. I found ServiceAuthenticationManager and ServiceAuthorizationManager but there is no samples available on how to code and wire those..
Can anybody suggest which way I should go?
Try to use this custom HTTP module. It will add new authentication mode to IIS and it will allow you using custom credentials validation.
I had all types of issues using the built-in annotations for WCF in a recent SOAP/C# project. I know this isn't the best solution, but for my purposes, I enabled basic authentication in IIS7 for my application, disabled anonymous authentication and created Active Directory users for the external clients that would call the web service endpoints. I then changed the application's permissions in IIS7 (it uses file system permissions) to allow a group containing those users.
This moves authentication outside your application, which may not be what you want, but does allow you to easily add users via the IIS7 console and deployment tools that can copy those permissions. The advantage is that you don't have to redeploy your application for permission changes. The disadvantage is you can't do fine grained permission control per function.
I'm looking for a complete step-by-step guide or a sample project about implementing a RESTful Service using .NET 4.0 using Custom Basic Authentication over HTTPS hosted in IIS.
I've been googling about it for 3 days and I could only find either an implementation with WCF 3.5 which is very different, or without Custom Basic Authentication, or without SSL.
Basically I implemented my REST service on WCF 4, and added SSL, but I can't use a custom authentication using my custom users database.
Any references would be really appreciated.
It's not currently possible using the available WCF extension points.
It is possible with custom HTTP module allowing basic authentication against custom credential store. Built-in module in IIS supports only windows accounts.
I wrestled with this for a while and ended up just implementing basic auth in my service. Check WebOperationContext.Current.IncomingRequest.Headers for an 'Authorization' header. If it's missing or the credentials don't match set the challenge header and return a 401 status:
WebOperationContext.Current.OutgoingResponse.Headers.Add("WWW-Authenticate: Basic realm=\"myrealm\"");
throw new WebFaultException<string>("Username and password needed", HttpStatus.Unauthorized);
That's enough to trigger a browser to prompt the user for credentials. See https://www.rfc-editor.org/rfc/rfc2617 for more on basic auth, http://ithoughthecamewithyou.com/post/Basic-HTTP-auth-for-an-IIS-hosted-WCF-4-RESTful-service.aspx for more on this frustrating missing capability.
Is there a clean way to expose a WCF REST service that requires basic authentication, but where we handle the actual validation of the username/password ourselves? It seems that when you tell WCF in config that you want to use basic authentication, it forces you to turn on basic authentication in IIS and IIS can only do basic authentication against window accounts.
The only hack we have found is to lie to WCF and tell it there is no security on the service and then do authentication outside of the WCF stack using a generic IHttpModule (which has a proprietary config file to indicate which URLs have which authentication/authorization requirements).
It seems like there should be a better way. Anyone have one?
The WCF REST Contrib library enables this functionality:
http://github.com/mikeobrien/WcfRestContrib
It also allows you to secure individual operations.
is the username and password set on the client like:
cc.ClientCredentials.UserName.UserName = ReturnUsername();
cc.ClientCredentials.UserName.Password = ReturnPassword();
Or are they embedded in the body of the REST message?
If the former, you can use a custom UserNamePasswordValidator:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
If the latter, you can set the service to no security, and use a custom ServiceAuthorizationManager to validate the contents of the message:
http://msdn.microsoft.com/en-us/library/ms731774.aspx
Hope one or the other helps! I'd try to post sample code & config, but I'm # home and dont have access to code, which is all # work.
See Custom Basic Authentication for RESTful services. Pablo's approach uses the interceptor functionality that is provided via the REST starter kit to solve the problem. If you do not want to depend on the REST starter kit, then you can create your own service host and use the inteceptor functionality provided.
If you host it on IIS, using custom http module is the way to go. You can bring over the principal over to WCF side to do code access security. See HTTP Basic Authentication against Non-Windows Accounts in IIS/ASP.NET (Part 3 - Adding WCF Support). Also see Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.
If you are not using IIS, you should be able to implement userNameAuthentication. See Finally! Usernames over Transport Authentication in WCF.
Yes absolutely there is a way. You need to configuring a custom userNamePasswordValidationMode value for your service and point it to a class with an overridden method that can inspect and validate the credentials provided. When making a RESTful call, these credentials when using Basic authentication in its proper form should be in the request header. With this custom method you can inspect the credentials and then authenticate the client to your service. No Windows accounts or domain even needed.
The nice thing is you can then take that security context to the next level and provide fine-grained authrization at the method level. You might have instances where a large pool of clients are able to access the service, but not all methods within (i.e. paid clients vs. unpaid). In this case you can also provide authorization at the method level as well if needed.
Below is a step-by-step solution (with too many steps to embed) by me that contains both the needed configuration and security required to have a complete solution. The problem is often Basic authentication is used without securing the Transport with a SSL certificate and this is bad. Make sure to follow all the steps and you will implement Basic authentication without the need of any type of Windows accounts or configuration on your WCF RESTful based service.
RESTful Services: Authenticating Clients Using Basic Authentication