I have been scratching my head for a while now. Went through tons of documentations but everything seems very confusing. Please forgive if it appears to be a duplicate question, but believe me, the more content I find, the more its confusing me.
Below is the configuration of my project and what I need to achieve:
The project is a web based application developed using Spring framework with Java 8 that is hosted on S3(linux server). HTTP server used is Apache. JBoss is used as an application server and the exact version used is wildfly-8.2.0.Final.
Currently, the user enters his credentials which are validated against Microsoft Active directory using LDAP and is let in. The requirement now is that when the user logs into the machine using his AD credentials in his intranet environment, and he tries to open the application, he should directly log in and not prompted for credentials again. If he is outside his intranet network, the existing log in method should be followed.
While researching I found the below things I assume can be useful but not able to reach to a conclusion.
Kerberos along with Shibolleth: I went through below two references which somewhat matched with my requirement but not very sure am I looking at the right thing or not.
http://richardjohnson798.blogspot.in/2011/10/single-sign-on.html
http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf
My confusion revolves around the below things.
Is Shibolleth the right choice. If yes, what is the exact role of Shibboleth?
What things needs to be setup on the linux server(Kerberos implementation for example), and what changes would be needed in the client's AD environment?
Is the implementation possible on the Wildfly server? (as all the references have the thing implemented using Tomcat).
What are the security aspects I should be concerned about.
Help is much appreciated. Thank you.
Since you are using S3 I assume you are using AWS.
Go to IAM and add the Active Directory as a SAML provider
https://aws.amazon.com/blogs/mobile/announcing-saml-support-for-amazon-cognito/
Then use AWS Cognito Federated Identity Pool via the JavaScript SDK in the front end code you have hosted on S3.
http://docs.aws.amazon.com/cognito/latest/developerguide/using-amazon-cognito-user-identity-pools-javascript-examples.html
Related
really hope that I can get some pointers with this before I go wasting too much time. In truth, I'm not even one hundred percent sure where I need to be asking this. I'm dealing with a whole heap of technologies I've had little to know experience with. Historically, I've been a pretty simple vb.net desktop developer so I'm learning MCV5 & C# as I go. I realize some of this might be in the wrong place, but hoping for pointers at lease
So the situation is I've been asked to develop a web application/api by a number of my customers so that their field staff can perform certain data entry functions while out of the office and periodically feed back into their management systems. All these customer have the very close to the same requirements and management systems, so my my intent is to build a single web application with a multi-tenant database where I control who gets to see what based on their login.
The core of the web app, database(s) etc I've got my head around, in fact that all seems pretty seamless. Using https://msdn.microsoft.com/en-us/library/aa479086.aspx as a start point I think I can manage the database side of things.
Where I'm really struggling over is how best to secure this system. Looking at the options in available to me in visual studio (2015) I think the best option for me is for me to use an On-Premise ADFS. My boss has already put his foot down regarding Azure, so unfortunately not an option, we pretty much have our own server farm in house more than capable of hosting this.
The real sticker here is my SA has pretty much said this is not his problem, if you want ADFS and a web server, you sort it out. He's given me a nice fresh server VM with Win2012R2 at least, but doesn't want anything more to do with it.
So, to the questions
Is ADFS even needed in this scenario, or am I better deal with this
all via a standard AD or some other tooling? And even if it is possible, is it a good idea?
Duringdevelopment/testing, is it ok to use a self signing certificate or
am I going to run into to trouble with certificate errors?
When configuring ADFS, you get asked for the federation Service name. In
the senario above where I'm using it for authenticating a web app,
is it ever exposed directly to the end user? Are they going to be
needing to type this in to their browsers? and will it be better to have external DNS entries for this?
My 2-cent:
There will be a learning curve, but if all the users are stored in AD, using ADFS will give you some advantages such as SSO, federation against other providers if you ever need it later on.
Using self-signed certificates during dev/test is fine. You can turn off certificate revocation check on ADFS side.
No, that Federation service name doesn't get exposed to the end users. I would suggest you have external DNS entries for your ADFS because your users need to access it from the outside. In short, a user rarely needs to type in ADFS url. Instead, he or she needs to access a service provider site and it will redirects he or she to the ADFS site.
This is becoming a more common scenario and can be seamlessly handled with AD FS. Ideally what you would want to do is:
deploy your AD FS farm
Configure your Web Application to trust your ADFS STS
Whenever you need to add a customer who will be using your multi-tenant application, add a federation trust with that customer (i.e. federation trust between your AD FS and the customer's AD FS)
This will ensure that you don't have to deal with identity management for every individual user when you add a customer. When a customer tries to login to your WebApp, then he will be authenticated against his AD FS, and your AD FS will get the token and sign them and present it to the Web Application. This will give them SSO which everyone has started to expect as a de-facto :)
Self signed certificates - As Thuan mentioned it is ok to use them during testing, just ensure that all your test boxes are configured to trust the certificate or otherwise you will be seeing connection drops all around
Federation service name - As explained in the setup summary above, the federation service name will never need to be exposed to the end user from a customer's organization. For all he knows, he is being authenticated against his AD FS as he is used to it already.
You might want to consider deploying AD FS in Azure:
AD FS deployment in Azure
We are wanting the ability to provide seamless single-sign-on into our web application. Our users are all using a modern version of IE and they will be accessing our website locally within an intranet, they will all be logged into Windows with AD accounts.
It seems that we can use integrated windows authentication to have the browser pass through the credentials, so this side looks fine.
But on the server side we have Apache 2.2 (hosted on Windows Server 2008+) with CherryPy sitting behind it - we use Rewrite rules to pass requests into CherryPy.
I have managed to find a windows compiled version of mod_spnego for Apache 2.2 (https://github.com/ibauersachs/mod_spnego) and I believe I have this configured in some way to authenticate the clients using their AD credentials.
However, we need to get these users details through to CherryPy somehow as we need to obtain further AD details over LDAP to apply permissions in our application (something that we already do but with simple username/password authentication first). This is where I have hit a dead end as I can't seem to find a way to do this.
I've seen various talk about the REMOTE_USER environment variable and suggestions for setting an extended header with the information we need in Apache but none of this seems to work.
Could anyone help me understand how to go about this? Apologies if I've not described everything correctly above, as I say I am new to Kerberos/SPNEGO and may be missing something obvious, or trying to overcomplicate things, potentially.
I have an ASP.NET MVC 4 application that is using CSLA.NET for a portion of our business logic. The permissions to read/write are handled through AD by a domain account, the same account as the Application Pool Identity and .NET Impersonation user. When testing on my local machine, the validation runs perfectly. Once the application is deployed to one of our test environments (dev or qa) I receive exceptions that seem to point to permissions. I've verified that the username being used by the assembly is indeed the correct user, but have been unable to set the values of any of the fields due to not having the appropriate permissions.
Anyone experienced anything like this before?
EDIT:
Link to discussion on lhotka.net forums
Web servers are stateless, so they don't generally remember anything between page or service requests. This includes the user's identity and roles.
If you are using ASP.NET forms security (or similar) the username will be automatically recreated on the server by using the .NET authn cookie token, but that's only the username.
You are responsible for recreating the complete principal/identity object on the server for each postback/request.
The easiest way to do this is in the global.asax file, often in the authenticate request event. There are samples in the CSLA download showing how to do this, and I discuss it in the 'Using CSLA 4' ebook series.
Also any good ASP.NET book will discuss restoring the principal, because this isn't really a CSLA issue as much as a web development issue.
I'm writing an application, and I've only had experience using a custom login module with Glassfish fo handling user login. If deploying in the Cloudbees cloud, I'm assuming that providing a custom login module is not a possibility, correct? And even if it is, I don't think I really want to use that method. What mechanisms do you use to secure you application, having user accounts, etc? If you use an OAuth provider, did you write one yourself? If so, can you point me to an example so I can do the same?
Thanks.
John - I have used openid in several places - that seems to work well. I expect a similar solution exists for oauth using servlet filters or similar.
The cloudbees "grandcentral" service is an openid and oauth (I think) provider - for cloudbees accounts.
In theory you should be able to do the same - even if you have to run an embedded glassfish as a zip of jar files with a main launch class.
We have an application that uses Active Directory for its Authentication. This includes Kerberos multi-hop delegation which the application requires. It consists of a WinForms client, connecting to a set of Web Services via WCF 4.0, hosted under IIS 7.5.
Normally, this all gets installed on our Customers own hardware and integrates with their AD. But we have recently set the Web Services running on private cloud (accessible via IPSec VPN) with its own AD implementation, and where we can set-up a one-way Active Directory Trust between our AD and the customers AD then all is well, and the application works as designed.
However, we have a few customers who are running their AD on Small Business Server, and therefore it is not possible to set-up the trust.
Given the following constraints...
A major re-write of the application to not use AD/Kerberos is not a viable option.
Forcing the Customer to move off SBS to a full Windows Server AD is not a viable option.
... I am looking at ways to solve this problem that require the minimum changes to the core Application as possible.
I can see 3 options that seem immediately obvious:
Active Directory Certificate Services - Clients use a certificate issued from our AD which is linked to an AD account in our domain. But unsure of whether this would allow the Kerberos Delegation.
Active Directory Federation Services - This sounds like it also could do the job, but we have never used it before.
Active Directory Lightweight DS - If the customer was to install this and somehow link it to their AD and we set-up the trust to the LDS instance, could that work? Again, we have never used AD LDS before.
Does anybody have any experience of this situation or something similar?
Does anyone have any recommendations as to which of the 3 routes to look down first?
Does anyone have any other alternatives?
The certificate will work for authentication and delegation. You should also look at protocol transition. This will enable you to do something like a forms based auth on your site and have it transition to Kerberos on the backend.
AD LDS won't do much here. ADFS is going to require alot of rework in your app as well.