I implemented SSO for my web applications with following architecture
These are basic flows:
Now conceptually it seems OK to me but what bothers me is the fact that all applications depend on SSO web api.
if something changes in SSO Web Api, all applications could suddenly stop working - what is good approach of versioning Web API to make it backward compatible?
If SSO API has DTO objects for users (username, email, roles, functions) that means I have to share them somehow with App1 and App2. I considered SOAP with wsdl but I would like to stick with Web API since its much more flexible client-wise and successor to WCF. One thing that comes to my mind is putting DTO objects of SSO API into separate class library project and referencing it in both App1 and App2?
EDIT: I need this for intranet applications with role/function based authorization
Regarding your two questions: There are well established standards for use cases like yours. Have a look at OpenID Connect and OAuth or the older, more enterprise-like, WS-Federation/SAML.
Anyways, rolling your own security is usually no good idea and a thing you should avoid (evidence). For a quite ready-to-use solution have a look at IdentityServer.
This looks like a home-grown SSO solution. I recommend that you don't build your own.
On the other hand, to answer your questions:
Q1: You have to version your API. There are several ways to version it. The easiest probably is to have a version number in your routing like:
"api/v2/sso"
Q2. If you have a DTO, you can create a library project that only contains the DTO. You can share the library by hard-referencing it as a DLL in your App1 and App2 project or you can distribute it as a nuget package. I prefer the nuget package - you can have a nuget server that is web based(hosted in IIS) or as a shared drive in your network.
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 building a set of services based on MVC 4. They should all be a part of the same authentication system. Currently I have got a separate project for all the model handling, including the Forms Authentication you get by default when making a new MVC 4 app.
Now, I would like to make a toolbar for logging in to our cloud services, and this toolbar must be made in such a way that it can be imported into our other services. Logging in with this toolbar should log you in to all our services, that are separated into different MVC apps. Thus logging in when browsing "service1" and then going to "service2", you should still be logged in with the same user.
Can anyone point me in the right direction here? Should I make a separate MVC app for this toolbar, and somehow reference it in all of my other projects? Should I export my controllers into a separate project and use them? I am not sure what the best practice is here, nor where to find the info I need on the matter.
Since you will be hosting your applications on different domains, you could implement some Single Sign On mechanism the way SO does it over the Stack Exchange network: https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work/64274#64274
Different domains means that you won't be able to share the Forms cookie. You should rather learn how to use one of the enterprise Single Sign-on protocols - using a recognized protocol means that you can easily integrate other applications, even if they are developed in different technologies (standarized protocols are supported by most development environments).
Possible candidates are:
the OAuth2 protocol. It is a respected protocol as Google, LiveID, Facebook, Twitter and others support it. To build an OAuth2 server you will need a framework like the DotNetOpenAuth.
WS-Federation. Got a lot of attention in .NET world as we got the Windows Identity Foundation framework which lets you create WS-Federation servers and clients.
Anyway, my advice is to invest your time now as this will pay off well in future.
I need to create a website in C# and need to use alfresco web service for process. In my site I need to create all the process that alfresco does through web service. I have seen the web services links in alfresco site. Its not documented as expected. I googled and found this one http://forge.alfresco.com/gf/project/dotnet/frs/
But this open source is in VB.NET. I need the same in C#. Can you please help me out?
Regards
Dipen
I suggest to consider other APIs before starting the developement of your application.
The Alfresco Web Services API is based on the SOAP protocol and it was the first API exposed by Alfresco. It was mainly created to work on Enterprise Services Bus (ESB) contexts and it could be useful only if you need to execute a vector of operations against the repository exchanging messages.
This API is based on a different model/schema called Content Manipulation Language (CML) that was created by Alfresco for managing remote calls. Personally I think that this is not easy to understand because it is quite different from the core model of Alfresco.
So I suggest to avoid the use of the Alfresco Web Services API.
Now the best approach that I suggest is to use CMIS (REST binding) or Spring WebScripts.
CMIS is a new standard supported by many ECM systems now and it stands for Content Management Interoperability Services. It contains some CRUDs methods to manipulate contents in the repository.
You could have some issues using CMIS only if you are using some specific Alfresco features that are not mapped in the CMIS specification.
The good point is that your client application based on CMIS can talk with any CMIS-compliant repository (Alfresco, OpenText, SharePoint, FileNet, Hippo, etc...)
Another good approach is to use the Alfresco REST API (WebScripts) that you can extend for your needs to expose REST methods that can be configured atomically.
This means that you can expose an HTTP method from Alfresco with your custom URL that can execute many operations in the repo but atomically. This means that if some errors are returned, the framework will rollback for you :)
I am doing a rebuild of a website and I'm trying to use an SOA approach. The current website is in .NET 2.0 and uses the out of the box SqlMembershipProvider.
We're trying to eliminate direct connections to the database and push everything through a WCF service layer. The approach we're using for this is to have everything separated - There's a library for models and interfaces, a library for the services, and then a library for the service proxies.
The biggest hurdle so far is figuring out how to manage user authentication and their session. What's the best way to do this with this approach.
Should we scrap the .NET membership model and go with something like OpenId, and just allow users to reconnect their data to the new account?
I've done some searching and can't find a lot on how to manage this, though I know it's been done before.
Here's what I ended up doing, in case anyone is interested. I started off using the WCF Authentication Services, but then realized it didn't give me everything I wanted. I could log on and off, but will still have to create my own methods for registration and getting the MembershipUser.
So I went in my ServiceContracts library and create an interface I called IMembership. At first, I created it as a class and inherited from MembershipProvider so that I could get all the method stubs generated for me. Once they were generated I modified the stubs and made it into an interface.
Then I went into my Services Library and created the implementation for the interface which was simple, because for the implementation I just used Membership.Provider....
Then in my Service Provider Clients library, I did the usual implementing of the IMembership interface, also inheriting from ClientBase<>. Right next to it I created a WCFMembershipProvider, which implemented MembershipProvider, and called the methods from the MembershipClient I just created.
In my WebApp that host the WCF Services I set up my SQL Membership provider in the web.config, and then created my svc file and endpoints for the service.
In the consuming web app, I just added the service client reference to the svc, and then set up the Membership Provider for my WCFMembershipProvider.
And viola - I'm in business.
A lot of repetitive code, but it works nice.
The principal problem you will run into when trying to create a WCF service and maintain the equivalent of session state is that there are no cookies (since there is no browser to maintain them), so the .NET membership providers are not going to be terribly helpful by default. I know how I have handled the equivalent issue is to have a generated token (for instance, a Guid) correspond with the state information I need to maintain.
Your question, however, is more about authentication. I don't know that you would be able to make an OpenId implementation work through WCF (though I understand it works great for plain old ASPX). You could use just a simple username/password authentication scheme (possibly using the MembershipProvider manually, if you need it for dealing with the password encryption in the database), and you can pass the username and password through the service using (most likely) Transport security (SSL).
I hope this helps somewhat. Maybe someone has come up with a more standard session-state replacement for WCF, but I'm not aware of it if so.
Hard to provide a specific answer without knowing a little bit more about your desired setup.
Do you plan to expose your WCF service as a public accessible independent of your website? Will your web pages access your WCF service directly via AJAX?
The easiest scenario is probably a strict layered deployment UI talks only to Website, only website talks to WCF Service.
http://msdn.microsoft.com/en-us/library/ms731049.aspx is a good read on using the ASP.NET membership model with WCF.
I built a site that used AJAX to talk to the WCF service layer. We used the forms authentication provider with WCF. It worked fine except that there wasn't a graceful way to handle the login through a web service. In our case that was fine as we wanted to the user to go to the website and login by entering credentials.
If you have already invested in collecting user's credentials to work with SQLMembership provider, you could surface it via ADFS+claims based model. This would work with all 3 of the above scenarios. There is a bit of learning to do though
I understand the term used all over social networking sites is "API",
I did some research on the web, and it seems to be a very big topic to cover.
As per my previous post, I have made a social networking site using asp.net 3.0 and C#. It's a small prototype.
A few tables such that the record of friends and their friends and their interest is kept. There are no privacy constraint at the moment
What I would like is to, "welcome developers please download the API for free and start making applications for the social network". Consider application extracts interests of the friends of a friends who is using the application.
From what I understand, an API is a space to host an application either provided by me or the developer.
APIs are an interface to (all or some of) the functionalities of your application. In your particular scenario you can expose Web-apis by allowing remote http calls (for example by using web services).
http://en.wikipedia.org/wiki/Application_programming_interface#Web_APIs
It's a bit more complicated than just "Right-click add API..." but you have a few options:
WCF, WCF rest, and Data Services / oData
If you're in a desparate hurry to get an API out the quickest way will be to use oData/Data Services, you basically make your database queryable via the web. (You can restrict Read/Write access.)
It's as simple as creating an Entity Framework model for your database, and exposing that as a WCF Data Service and you're done.
http://msdn.microsoft.com/en-us/data/bb931106.aspx
http://www.odata.org/developers/odata-sdk