I'm a programmer with VERY limited system experience, and I've set up an ADFS 2.0 Rollup 3 server for authentication to Salesforce.
My use cases are:
1. Allow single users to authenticate against their NameID in the UPN.
2. Allow group users to authenticate by membership in a user group.
I would like to have both types of authentication on the same ADFS server. Here is an example of the sign-on screen, where the "Active Directory" button is for single users, and the "Admin Users" are members of a user group.
I have no problem with either group authentication or user authentication on a single ADFS server, but I'd like both on the same ADFS server for a single relying party trust. However, I haven't been able to get that to work.
The entityID is the default,
http://[Server Name]/adfs/services/trust
The login URL is the SAML 2.0 endpoint:
https://[Server Name]/adfs/ls/
I've tried several things that didn't work:
SalesForce requires the "issuer" (in this case, the entityID) and the "login URL" together are unique, so I've tried adding URL parameters to the login URL, since those will get imported into ADFS from the metadata file. That doesn't work though - If I have two relying party trusts, one w/ the parameters, and one without, I'll get signed into one, regardless of which one I'm trying to sign into.
I've also tried adding multiple rules to one, but that generates an error when I try for SSO.
How could I get this to work?
If anyone ever stumbles across this, in order for this to work, the simplest solution is to send different relying party IDs from SalesForce, and have different relying party trusts in ADFS.
In SalesForce, this would appear as two different buttons on the login screen, and in ADFS, this would appear as two different relying parties - One in each system for each relying party ID.
If you are auto-signing in from some application, you'll have to iterate over each relying party trust, and try to authenticate from each.
I can't imagine this very specific use case will be much value, so comment if you want more details, since my 3 year old question has little interest :)
Related
Please help. I'm aware there are several posts / docs about SSO implementations but I still can't seem to find one that addresses my use case - probably because I'm still new to SSO implementation.
Scenario:
I have an existing Symfony 4 application with existing users. I want so that when users log into the app, they are automatically signed into Outlook Office 365 (web). Exactly the same implementations on https://mysso.centennialcollege.ca/. Please NOTE I do not want office 365 to authorize my app using the code flow approach, rather I want office 365 to recognize users signed into my app as valid identities.
Has anyone implemented this or has ideas please?
Your question is a bit unclear. You're likely going to need to change the existing application in some manner in order to achieve true single sign-on. You'll need to ensure that authentication against the Symphony app leads to the presence of a session that can be used to trigger subsequent sessions in a SSO framework supported by O365.
In your case, I'd take a look at SAML and, more specifically, SimpleSAMLphp.
Are you affiliated with the organization you linked to in some way? Because just by looking at the login page that looks like they've already got some sort of SAML Identity Provider solution... you can just integrate your Symphony app with that IdP in that case, and correlate the principal returned to your SP application from the SAML assertion on successful authentication against the user data in your existing DB. You wouldn't have to use SSP in that case... any kind of SAML middleware would work.
I have multiple applications (made with different tech such as .NET, JSP, PHP, ... ). Each one of them have its proper login page which contacts the LDAP to verify the username and password (there is one LDAP for all the applications).
What I want is to do a SSO for these apps: One login page is to "rule them all".
The user enters his credentials once.
He chooses an app from list.
The app will load without accessing the original login page.
My additional questions are:
Is there anyway to implement a SSO solution without modifying the apps's source code?
Is there a trick to pass the username and password to the original login page and submit automatically?
You need an IdP, something like Shibboleth IdP or ADFS, which will handle the users from an Authentication Source and do that hard stuff like the login page, etc. Usually there's user management headaches here, i.e. how will users change their passwords, etc. That's where a commercial solution like Okta, Ping, or OneLogin might work better for you.
You need a SAML Service Provider for each of your apps (what SAML stack you choose largely depends upon tech used in site), or you can use something like Shibboleth SP which simply protects paths on the webserver. If the apps are all on the same one or two web servers, go with Shib, as it'll make the integration with ADFS simpler.
If you want to avoid modifying source code, something like Shibboleth SP is probably for you... it protects paths, and loads user attributes into server variables you can pull from (i.e. username, first name, last name, etc.) to render on your app.
I'm working on setting up a service provider that supports SAML. I've added two identity providers - one custom one that I built from SimpleSAMLphp and then ssocircle. So I log in to the selected identity provider, and then it returns to my service provider and I inspect the attributes of the SAML Auth object. The identity provider I built returns whatever I want it to (obviously). The ssocircle one only returns e-mail, first, and last names.
So now to map this to the user of the service provider, I have to use some value the identity provider provides. So this led me to wonder how it should be done. Since ssocircle only gives me e-mail as a useful value, do I just use the e-mail to map to the SP user?
Let's pretend for a second that ssocircle doesn't validate e-mail addresses. So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges.
So my question is, do I handle this? Or is the onus on the admin who set up the identity provider and say "well you shouldn't have used an identity provider that doesn't validate e-mail addresses!" or something of that nature? Or should I only allow identity providers that pass a certain value, like userid or 0.9.2342.19200300.100.1.1? Is there something that identity providers commonly use?
Well, you said it, two different identity providers. They both should be passing not only the email but different entity ids and certificates.
In multi-tenant applications that would mean two different applications, but if you plan to allow multiple IDPs to point to a single app you will need to ensure that same email but different entityID create two different users and or throw an error after the first was created that the second cannot be provision nor access.
Interesting question. These days people think always of auto federation of users by some attribute. In early SAML federation days federating two unrelated users was a manual step in which a user logs in at the IDP and logs in to the SP providing both sets of credentials and then manually federated these two user accounts. The process guarantees that only the user who has access to the accounts at the IDP and SP controls the linkage between the two. It also allows anonymous naming identifiers (SAML persistent NameIDFormat) which protects privacy because even the IDP does not know the user name at the SP and vice versa.
Unfortunately the process was to complicated for users and with the success of OpenID the aspect was getting less and less important.
To answer your question: What you describe happens in the real world -see Office 365 authentication bypass
You need to check that the IDP is authoritative to send a specific attribute and attribute scope in case of two IDPs.
In case of one IDP the attribute must be verified (SSOCircle verifies email address) and it should better be unique (For example SSOCircle userId) to avoid that two users with the same attribute are mapped to a single user at the SP.
If the userid's are not the same (e.g. you use a simple user ID at the IDP and email address format at the SP) you can still add a correlation attribute at the SP (e.g. an attribute named ssocircle-userid) and use that to link the user accounts.
I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
I'm working in a company that uses Microsoft Active Directory. We have an external company that provides an internal web site for a particular project. The site is external to the company. The sign on to the external site is the user's company email.
We want a system whereby the external site calls into the organisation's AD to verify if an email address is still valid or if the user has left the company. It should be a simple call to Active Directory Federation Services or some sort of SAML interface. The call would be a simple request 'here's an email, is it valid?' and the response is either yes or no.
Our IT department are trying to tell us that it's too complicated and I don't believe them. I think they just don't want to do it.
Does anyone know how easy it would be to create a simple system that would allow an external service to do the query outlined above.
ADFS is not meant to do that. However, a by-product of using it, would be the validation you are looking for.
The first question would be: what is the authentication method of your app? e-mail and what else? password? which password? Does the app keep a database of users/passwords?
ADFS works as an "identity provider" and would authenticate users in AD. ADFS would supply a security token that can be consumed by your app. Part of the information sent in the security token could very well be (and often is) the user e-mail address (that's why it is a "by-product").
For this to work, the app would have to be changed to accept security tokens (SAML tokens to be specific). If the app is .NET based, then it is done usually with WIF (WIndows Identity Foundation).
This approach would be the most elegant and secure because the app would delegate the responsibility of authenticating users to the authority of these employees: AD.
App --trusts--> ADFS --authenticates--> AD
Setting up ADFS, etc is not super-difficult, but it is not super-simple either, and might not be worth just for this app. There are other lighter weight alternatives: open source products like Identity Server, or products like the one I work on.
Now, if all you need to do is to validate that the e-mail actually exists, the best is to send a verification message to that address with some unique code that the user sends back. This is the same approach used in many common web apps.
Agree with everything #Eugenio said - have same questions about authentication.
But if you simply want code to query an user's email address in AD, you use the AD API's.