We do not have ADSF at present, so I cannot test this, but I would like to know if it is possible to authenticate onto a separate domain, when only signing on locally (but using domain credentials).
EG
I have a laptop that is part of a domain (WORK-DOMAIN). The plan is to use ADSF to authenticate and make use of some resources on a separate, currently untrusted domain (RESOURCE-DOMAIN).
My question is, if I'm working from home, I am logged in with my domain credentials, but I am not on the network (I don't VPN on to the network). Will ADSF accept me as being authenticated on the domain, even if I'm not currently on the network?
I hope this makes sense... Thanks in advance.
adfs supports several authentication methods. You could use forms based auth to pass your username and password when at home to adfs. When on corporate network you'd use windows integrated authentication. The key thing is to ensure adfs service account has the ability to validate credential of user. This is where your domain setup and trusts matter. As an example if adfs servers and service account were all in user domain then this is simply and works.
You need an ADFS per domain. So you would have ADFS-WORK-DOMAIN and ADFS-RESOURCE-DOMAIN.
You are not part of the RESOURCE-DOMAIN so when you navigate to it, you will have to use Forms Based Authentication and use the credentials on that domain's DC.
If you federate the two ADFS and you are at work, then you will be able to access RESOURCE-DOMAIN via WIA using your WORK-DOMAIN credentials. This is because the two ADFS trust each other.
Related
I need to restrict access to an external site so that:
users who are in the corporate network have full access to the site's functionality,
those who are not - only limited functionality.
In the corporate network users do authenticate against a windows domain. In the network I can set up a server/service which can do the identity verification. This is secure, I have no doubt, especially when it is inside.
The external site is not a part of the domain.
What I suggest to myself is to setup a service, which will authenticated users against, create a secure token and then re-direct users to the external site. So that users will authenticate there without entering password (maybe not even login).
I'm in doubt: how this can be done? How secure this can be? How much heavy/crypto development are there?
I assume that the secure token should be time-bounded, that both external site and internal auth service should support SSL/TLS (symmetric/asymmetric keys?).
Am I missing something here? Surely, I am, but what?
Make the external site a SAML 2.0 Service Provider (SP).
Set up an internal SAML 2.0 Identity Provider (IdP) to authenticate the corporate users with SAML 2.0 ADFS. Use SP initiated SSO and have the external site configured to hand off to your IdP with HTTP-POST.
The IdP can be configured to authenticate a user logged into your ActiveDirectory domain with a browser capable of NTLM transparently. It should just authenticate them and sign an assertion to that effect and redirect them back to the external site. If they don't have NTLM they'll be promtped for their domain credentials first.
UPDATE: as noted by #Steve the external site still needs to authenticate external users. Making your external site a SAML SP doesn't solve that. You could have the external website do some built-in authentication or you could have a different SP endpoint (URL) for external users and use another IdP for them.
We have an application that checks against active directory for valid UN/PW combinations with a simple LDAP query. That query simply responds with a message of yes or now to validate the user. Unfortunatley we have no control over this application so can't make it a claims aware applicaiton which would provide AD access to the user.
Is there a way with SAML or something to log a user in to AD / ADFS with only their email address (UPN) so that we can then provide them access to other services on our domain?
Ultimately, we are going to use the token to SSO the users to an Office365 implementation that we have.
ADFS will authenticate against AD via several methods, one of them being username/password. You don't need your homegrown application.
We have number of intranets sites, hosted in web logic server, each have its own authentication framework. Now we have a new requests to implement the single sign on. There is another team who are communicating with active directories [pass the domain name and username like phillip_r and it will return the primary email etc], how do I utilize , I read few article about CAS, Kerbos etc and now I more confused do I need to implement them in my case or not, please help me on this, as I don't know where to start.
WebLogic is not 'kerberized' so you can not actual use Kerberos. However you can use WebLogic's SPNEGO handler to provide 'auto-login' from user perspective this is like 'single-sign on' but actually it's only 'auto-login'. The Kerberos token provided via SPNEGO typically has 'userpricipalname#REALM' ... that can be email address, but most of the time it's not email. It will not return arbitrary attributes from AD... you have to do this own your own (e.g. via LDAP).
However Kerberos via HTTP (SPNEGO) only works for enterprise clients, which can directly communicate with the Key Distribution Center (AD KDC).
CAS or OpenAM (http://openam.forgerock.org) are web-based, java-based single sign on systems which offer different means for authentication.
As long as all apps are on Weblogic and all users are in AD domain, you can use Kerberos SSO for all of them with no problem and don't need CAS. Set it up using instructions from Oracle.
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...