I am developing a .net application using Web Services, and the application is consuming them using Spring.Net WebServiceProxyFactory.
I need to send to the web service the username and password of the user that is logged in to the application, consuming the web service.
Reading some forum post (like this http://forum.springframework.net/showthread.php?t=4818) they seem to refer to an example that used to be in the spring documentation ( http://www.springframework.net/doc-latest/reference/html/webservices.html ), an example of how using SOAP headers for authentication using the WebServiceExporter and WebServiceProxyFactory, but the link to the file is broken.
Do you know a way that I can send the user credentials as a soap header using spring.net? Or any data (for example, a token ID that the web service will use later to get the user credentials).
Thanks.
Here is something that might help you
http://www.codeproject.com/KB/webservices/SOAPHeaderAuthentication.aspx
Related
We have a whole bunch of clients that want us to start using their ADFS to allow their users into our web app using Single-Sign-On.
After reading up on WIF (which seemed to be the solution at first but is deprecated in VS 2013...), OWIN, oAuth, OpenID Connect, I'm completely confused as to the simplest way to implement SSO.
What is the best and simplest technology to use to implement SSO on an existing VS 2013 json restful service written in C#?
Ideally the technology would already be part of .NET.
Are there any code samples or tutorials out there for this scenario?
assuming that you want to consume your service from native clients, I would recommend that you protect your service using Web API middleware (which was already supported via OWIN middleware in VS2013) and implement your clients using the ADAL library. For a post specifically on ADAL and ADFS, see this. For more details on the Web API side of the solution, see this. If you want to target a variety of client platforms, you can find a complete collection of samples (for Azure AD, but easy to modify for ADFS) here.
This can be implemented through WSO2 IS as Relying Party in ADFS. When we will implement this setup the outcome/Income claims will be main source for User Profile load to WSO2IS for authentication and pass the SAML Response to SP(End URL of your application).
Refer the below links to configure WSO2 IS as relying party for ADFS and WSO2 IS configuration too.
https://omindu.wordpress.com/2015/06/19/setting-ad-fs-3-0-as-federated-authenticator-in-wso2-identity-server/
SSO would mean its Active Directory driven, or direct to IIS machine.config authentication instead of a web.config, but also considering the "simplest technology" you've mentioned, then this must be a call for something simple yet you can transform into what you really desire.
With this, we can refer to token-based web services authentication.
Here's a sample project from which I started and able to transform into something else. From here I think you can then change all authentications into AD or DB connect, or even both across your web services.
http://www.codeproject.com/Articles/9348/Web-Service-Authentication?fid=145460&df=90&mpp=25&prof=False&sort=Position&view=Normal&spc=Relaxed&fr=26#xx0xx
hopefully this would help.
I am creating Android Application for a school where teachers should be login to the android application and perform some activity on daily basis.
We have a complete existing web based solution for the same and now want to implement same in Android.
The application is developed in Asp.net and C#
To authenticate a user on android login, I have created a login API which takes username and password in the query string and in return the API return Json Data From That User.
example : www.yourdomain.com/authenticateuser.aspx?username=xxxx&pas=YYYYY
But I doubt whether its safe to send the data via query string.
Can anybody suggest a better possible way where it is not mandatory to send the data in Query String.
You can use Soap based web-service. I created a demo to consume Soap Web-service without KSoap Library.
Ref Link: SoapWithoutKSoap
You can use KSoap Library to create complex Soap Data Request.
I hope this can help you.
C# Web-Service: Demo and Demo1
UPDATE
Web Service Link will be something like this : http://123.456.789.012/Abhan/Abhan.asmx?op=JustTest (This is not working as I modified the IP Address)
In Browser, method name and passing parameter(s) information will be like something as attached image.
Thanks.
I'm using C# web services to autenticate users, send report data and get app updates.
You can get some exmaples in the web (C#):
http://msdn.microsoft.com/en-us/library/8wbhsy70%28v=vs.90%29.aspx
and ksoap2 for Android:
http://code.google.com/p/ksoap2-android/
But I also bought a SSL certificate to use https...
here's my setup:
I have an MVC3 site hosted with a www subdomain (e.g., www.example.com). My site is secured via SSL and forms authentication, backed by ASP.NET membership/role providers. I have HTTP handlers providing service capabilities under /services (e.g., www.example.com/services). These are secured through Basic authentication over SSL. I have mobile devices successfully accessing/consuming these services. I have also created a new site with an api subdomain (e.g., api.example.com) that will be my public-facing API. These services are exposed currently via WCF Web API preview 6 (eventually to be migrated to ASP.NET Web API). These services are also secured via Basic authentication over SSL. My ASP.NET membership implementation stores hashed passwords (i.e., they are not encrypted). All services serve JSON responses. All of this stuff works great.
Here's my dilemma:
I started to write a new view on the MVC site and realized it would be great to use Ajax. My specific case is to implement cascading drop-down lists. I wanted to implement this using jQuery and a new service under the api subdomain. At first I thought this would be a simple exercise and then I realized, I have no effective way to call into my own API. My clients (mobile devices) all store their username/passwords locally so this is easy. However, if the same user is logged into my site, I have their username but not their password so I do not have a direct way to access any services offered under the api subdomain.
As I see it, I have three solutions:
Implement services that support the MVC site directly under the /services URI, eschewing consuming my own public API.
Create a super user in my membership store (where I know the username/password) that the site uses to access services in the api subdomain.
Change my authentication strategy.
It occurs to me that I probably should not utilize my own public API and would be better served using my own private services (which is ok because the logic is all shared via a facade layer).
What is the recommended strategy here? I also assume that if I were to utilize option 2 or 3, I would have to do so using JSONP. Is this correct?
Any advice would be greatly appreciated. And if more details are needed, please post and I will update with answers.
Thanks!
If Im following this correctly, you simply need to make sure your Forms Auth cookie is written with no subdomain so it would be: .example.com and if you are using separate servers, you share your machine key across them.
Since forms auth tokens are stateless and nothing is kept on the server side, this should work fine.
For simplicity and because I decided it was not in my best interest to consume my own public API, I implemented JsonResult actions on a new controller in the existing MVC site. This allowed me to utilize the existing forms authentication and avoid the cross-domain ajax requests.
I'm writing a new desktop app as a smart client. Although it will need to cache some data locally, data will be downloaded and commands issued via a WCF web service.
So that "not just anyone" can call the web service operations to get data or issue commands, I'd like to use forms authentication. I'd like users of the desktop app to log into it with their website credentials (all on the same domain), and from them on for the app to supply the "token" (cookie or whatever) with each WCF request, so that the WCF service can authenticate/authorise them.
Is this possible, and could someone point me in the right direction (keywords, tech to research), please?
I know that I could "roll my own" where I have an authentication service that will return a token, and that each web service operation could require a token that it will look up authorisation information for, but it seems we already have this in the ASP.NET membership stuff, so I'd like to make use of it.
Many thanks in advance.
If you are using VS 2010, it is build it, you just have to select in the project properties, and then click the Services tab. MS changed the name to Client Application Services. Just check the Enable client application services and then fill in the blanks.
Here is the whole help section on it from MS...
http://msdn.microsoft.com/en-us/library/bb384297.aspx
i could not find any idea of how to implement API over the SharePoint(MOSS) framework.
Could anyone give me a tip please?
What i want to do is create a client application to communicate with the SharePoint.
wanting to implement something like following.
Client send post request to API implemented on SharePoint, API receive a request and do the authentication and create a login cookie.
Client keep communicating with API(with the login cookie), request necessary information and API returns it.
I could not find anyway to hook a program...
Is there anyway to hook a program or implement own authentication mechanism before SharePoint's own authentication is called?
Any alternative approach will be grateful.
Thank you in advance.
Taiga
It sounds like you need the Web Services that ship as part of SharePoint. There is no need to re-invent the wheel by creating your own API.
If your own application runs on a machine with a local SharePoint installation then you can program against the SharePoint Object Model directly. Otherwise use the Web Services interface.
More on Google.
Here you find a fluent API for the SharePoint. FluentSP implements a modern fluent interface around the classic SharePoint 2010 API:
http://www.parago.de/2011/09/fluentsp-the-fluent-sharepoint-api/