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.
Related
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
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.
We have a scenario where we have to authenticate the user with LDAP server
Flow 1:
client --> application server --> LDAP server
In above flow the client enters LDAP credentials which comes to application server and then using python-ldap we can authenticate the user, straight forward. Since the user LDAP credentials comes to application server an organisation may not be willing for such flow for obvious reasons.
Flow 2:
client --> oauth2 --> LDAP server
Oauth scenario suites best here, since authentication of the user is responsibility of the oauth and application server do not need to know the user credentials.
Have anyone encountered such case, if yes, how you tackled it?
Is there are any Oauth client for LDAP free and paid ?
If you don't want user credentials to reach the Application server then what you need is a perimeter authentication. You need to have an external authentication provider , say Oracle Access Manager, that will perform the authentication and set a certain token in the request. The application server can assert this token and let user access resources. This model enables SSO as well.
The resources that require authorized access are configured as protected URLs in OAM.
When a user tries to access a protected resource he is challenged for credentials.
OAM authenticates the user against an LDAP directory(that is configured in OAM).
A token corresponding to the authenticated user is set in the request. Also an SSO cookie is set.
Application server (Weblogic) can assert (verify) this token and let the user access the resource.
Note: Oracle Access Manager supports oAuth as well.
Ory Hydra https://ory.sh/hydra might be what the original poster was asking for. This question is several years old now but in the interest of helping anyone else who sees this...check out Ory Hydra. It provides the OAuth2/OpenID parts and can be linked to an LDAP server behind the scenes.
canaille is a free and light OAuth2/OpenID service over a LDAP backend, written in python. (canaille developper here)
https://gitlab.com/yaal/canaille
I am a little bit confused about the terms of authorization and authentication. I know what each term means but combined with different Single Sign-On services I've got some problems with a consistent terminology.
What I am confused about is that, for example, CAS ( Central Authentication Service ) is meant to be used for authentication AND authorizationk. For me authorization would mean, that there is a functionality in the implementations, so the server decides if the user gets access to a different service or not.
But as I've seen, for example in CAS, that authorization for them is only sending different user attributes to the service and it decides whether the user can access or not. But is CAS then really providing a authorization? Is this not just authentication and then giving some attributes to another service which then decides whether the user can pass or not?
tl;dr:
Is sending user attributes to a given 3rd party web service so he can decide whether the user gets a login session or not already authorization by the SSO service, or is it just helping the 3rd party service to manage authorization ( so the SSO service does NOT provide authorization, just authentication) ?
CAS is not an authorization service. it is build to support authentication with single sign on and it can not authorize anything, the only authorization part it can help u with is to send u some user roles as attribute and u can use those roles as `role authorization'. for more than role authorization u need to implement your own authorization system (maybe embedded in the application that is using cas as authentication?)
Overview
Our SharePoint 2010 application will be launched from a 3rd party application, let's call it HealthApp, via an embedded URL. Much of the time the user will be logged into HealthApp from a shared workstation. As a result, SharePoint will not sign in automatically using the Active Directory credentials.
Requirements
We need single sign-on.
We need to continue to use Active Directory as the STS for various reasons.
Authentication from a stand-alone browser on the user's workstation will need to work as it does now.
Authentication Info
HealthApp can pass a username and any other custom identifier information we want as URL parameters.
The username will match the users Active Directory username.
We will not have a password.
We need some way to authenticate the user based only on the username/identifier.
Possible Solutions
Is there any way to bypass the password check in Active Directory?
This would appear to be the simplest solution if possible.
Can we
extend the Active Directory provider to authenticate using a generic
user and then log into SharePoint with the username passed on the
URL?
Any other suggestions?
I would think there would have to be some way to do this but have not had much experience with claims based authentication with SharePoint.
Thanks for any insight.
Me also facing same issue for authenticating users over share point site that uses claims authentication.As per requirements my app needs to access share point data. So to authenticate
over share point server from an app we need to provide some authenticated claims with the request so that share point STS can issue an authorization ticket to access the share point site resources. after spending more than 2 days in googling i found some interested article that may help to authenticate users from client app against identity provider systems.
OAuth library
this resides between app and identity provider system. using this you get an authenticated claims that will further use to authorize over share point server with the help of Share point STS.