I'm attempting to implement a saml service provider, but i'm not sure what level of system to cover with a single SP.
What level of architecture per SP is considered good practice? Should we have one for our entire department, per server, per domain, per application pool or even for every site?
Our organisation has a shibboleth IDP and i'm using kentor authservices. Its working for one site but the sp is part of that site.
Assuming best practice is not one per-site if anyone has a hint on how best to approach making it more generic (i.e. one entityid for multiple sites) that would be appreciated.
Somehow you need to get the login information into each site/application. Either you use an SP per site (which is the Kentor.AuthServices approach) or you set up a Shibboleth SP proxy in front of the web apps. The latter means you have to add code to each site to parse the http headers that Shibboleth delivers. I don't like that approach - that's why I started the Kentor.AuthServices project.
So, my preference is to have make each site a proper SP through a module that is as native as possible for the web application framework. Modules that might be relevant are Kentor.AuthServices (.NET), SimpleSamlPhp, Spring (Java), saml2-js (node).
In the case that you organisation have multiple sites/applications that you want to federate with multiple upstream Identity Providers you will get NxM pairs of configuration, which is not scalable. An option in that case is to insert a SAML2 proxy that acts as Idp to your internal applications and as SP to the external Idps. New sites/applications only need to be configured in the proxy and new external Idps only need to be configured in the proxy.
Related
This seems like it would be a common scenario but I can't figure out how to get it work.
I have a Common Web Service located at origin 1. I want this to be common between multiple web applications. It has authentication turned on.
I then have Web Application located at origin 2. I want this web application to make some calls across to Common at origin 1 (via javascript)
These calls work fine if I turn off authentication for Common at origin 1. If I turn it on, it fails since the web application will not send the authentication cookie (or token?) across origins.
What is the correct way to architect this?
You want to look into what is called delegation. The scenario works like this:
User authenticates against AAD in your front-end app
A token gets issued that is valid for the front-end app and the backend-app (this is the delegation)
You use the token provided and forward it to the backend-app and issue the request on behalf of the user
How to set this scenario up is described here but you really do not need API Management in the middle. The reason for using APIM makes sense if you want to expose your API to the outside world too or have multiple APIs that need to act as one facade.
We manage a website that runs of the .NET 4 framework and we need to implement SAML 2.0 to support single sign on. We do not wish to run Active Directory federation services as all user accounts are stored in a SQL server. What do I need to consider when developing a single sign on service whereby we are the identity provider?
I work with SiteMinder Federation Services (SMFSS) and Federtation Manager for CA. Are you planning on also doing Authorization for the SP based on Attributes? Do you have an Authorization SSO Solution already? IF so what is it? If it is SiteMinde then the fastes easiest to impliment solution would be SMFSS. Aside from from ServletExec and Java JDK bugs which are pretty much fixed up now I can get customers who have never used Federation up and running in a day for a SAML 2.0 POC. So, if you do have SiteMinder I would give that a try and I am sure you will be quite pleased. If not we also have Federtion Manager which can run as a proxy into your site or not. We have customers who do things such as use the SiteMinder access logs to charge users for access to SP sites a certain charge per access. We have the attribute Authority so that if you want to provide Authorization based on user attributes you can do that. If SMFSS is on the SO side you can just have the attributes stored on the SPO sides session store. Can you tell more about your use case? When SiteMinder was orignally created one of the uses cases was for SSO between different web servers, etc.
Let me know if I can help with any follow up questions and have a splendid day!
Thanks!
Crissy Krueger Stone
CA SiteMinder Support
Based on your initial requirements, you should take a look at PingFederate from Ping Identity [Note: I do work for Ping I'd]. It can support multiple databases and directories simultaneously as well as provide multi-protocol support in both an IDP and SP role. We can also support different development languages you may have beyond. NET.
HTH- Ian
If i had two different application running under the same solution but using different Databases can i share User credentials between those applications ?? any solution other Than The SSO and the Machine key in the web.config where the authentication is based on the default Asp.net Database ( i guess it's called the membership database )
if their is a solution could You please help
Are it two seperate IIS websites? And what are the real requirements you have? Just share some variables or move data from one application to another?
I'd think you'd probably better look into creating a service layer to receive and send information between sites. This way you can eventually seperate the two applications on different web front ends without problems.
This service layer can be implemented using different techniques like XML Web Services, WCF, or maybe you could look at the new ASP.NET Web API http://www.asp.net/web-api
edit:
Ok clear from the comments I got some more info:
Imho you could do two things: schedule a synchronisation using some mechanism (could be xml export / import) every day or so. But if you'd want realtime SSO, you could simply create a service on the webserver connected to the authentication database where the only functionality is to authenticate users. Something like a: bool validatecredentials(string username, string passwordHash). If you're not talking about thousands of authentication requests this will perform quite good using standard WCF or some other service technology. If you are talking about larger systems or implementations you should look at Claims based authentication, .NET has a technique called WIF to implement that. It works using a seperate STS (Security Token Service) to issue tokens with claims who a user is and what he is allowed to do, etc.
I have an Asp.net application 3.5. I want to be able to allow multiple/ different clients to access the same application but using different URL's. I have already managed to configure the database to allow this.
So here's the main part.
I want to host my application in a domain say...
wwww.myapplication.com
then allow different client to access the same application using
1) www.clientOne.myapplication.com
2) www.clientTwo.myapplication.com
Also the client subdomains i.e(clientone.myapplication.com and clienttwo.myapplication.com)
should be autocreated by the client upon registration.
How can I achieve this..Your help will be greatly appreciated
A good example of how I want my application to work is
www.quickschools.com
I finally found out the solution that I wanted, so I thought I would share with you my finding. It turns out I needed to create a web application from another running Asp.net web application (From C# Code)
This tutorial by Robbe Morris was really helpful if you need to get started on this.
Another article you might want to check out is this one.
To have different url's using the same application, i would use "301 redirect" subdomains. I'm not really sure how to have a webapp create these subdomains.
I think the way to do this is to make the website the default website on the server i.e. configure so all requests to the servers IP hit this website (unless the header matches another website that explicitly looks for it). You do this just by not specifying a header on the IIS settings (only an IP address and a port number) - you can only do this for one site per IP address/port combination on the server.
Then look at the request url in the website to determine which domain was requested.
This way there is no need to 'create' subdomains... but you do need to reject all request to a domain that you don't want to recognize.
If you can't do this then you would need to adjust the IIS metabase from the application - not impossible - but a very risky and probably a bad idea.
The common case is that you'll have to configure a new virtual site for each of your new tenants during account provisioning. See Creating a New Virtual Server on how to achieve this programatically. Some though argue (with convincing arguments...) that spinning up an appdomain for each tenant is a waste of resources and one should use routing in the application that inspect the HOST header, see Multi-tenant ASP.NET MVC – Introduction.
Configuring IIS/ASP to respond to your tenant sub-dmains is the easy part. The real problem will be to configure DNS for your tenants, and that depends on your DNS solution.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.