I'm trying to set up a single-sign-on solution to a 3rd party site. They currently don't have anything set up on their end yet, but they want to use SAML. They instructed us to "provide them a sample of a standard SAML2.0 message", and sent over a certificate. Kind of asking me to show them a key and they'll build a lock to put it in.
I need some direction on what to actually set up for this. The vendor has cryptically stated that they are using these parts of the SAML message: ds:Signature, saml:Conditions, samlNameId. I've put together a C# console app that can produce a Saml2SecurityToken using their certificate and a given Name Identifier, and set a timeframe for the condition. I think this is what they need from me.
We do have ADFS however. I've used it to authenticate users accessing internal sites, so I have a little experience with it. I'm overwhelmed by the information for ADFS though, and can't grasp what to set up for this kind of situation - I don't know how to translate the vendor & I's relationship into ADFS terminology.
Can someone explain who I am and who they are in ADFS terms? I think all the pieces for setting this relationship are right there, but I'm just getting swamped by the volumes of information on every page about ADFS.
On your ADFS site, navigate to:
https://your server/federationmetadata/2007-06/federationmetadata.xml.
Save this file, send to the vendor. This is the metadata. It describes the SAML profiles, the certificates, the public keys etc. You don't need to send them any actual certificates.
Ask the vendor for their metadata. Import this into ADFS as a Claims Provider Trust.
Configure your application via WIF to use ADFS.
When the user navigates to the application, the user will be redirected to ADFS. They will get the Home Realm Discovery screen and select either the 3rd party vendor or ADFS to authenticate and then they will get access to the application.
If ADFS is the source of authentication ADFS is the IP, the vendor is the service provider (RP). And obviously vice versa.
Related
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
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.
What I know so far is, to make any application SSO enabled, there must be an Identity provider taking part in the SSO game. So there is direct dependency on IDP as the SP need to "know" who the IDP is. Can SP have a common saml communication mechanism which can work with any IDP that my customer is using ? Or I need to build different saml communicator based on the customer supported IDP ?
Reason: One of our company customer is using Okta for its employees and want us to make our application Okta enabled so that its employees need not to remember credentials on our site anymore. That's fine. Now, if any other customer comes with some other IDP (PingOne for example), do we need to work again to make it that xyz IDP enabled ? or our existing implementation will work same way by just adding that IDPs url ? Let me know if I am missing any big picture or key concept here.
P.S. Our application is on .NET platform.
Unfortunately you will need to create a new association if a user want to use a new IDP.
There is a good reason for this. You need to be say that you trust the IDP. The IDP is the one that vouches that the user is who they say they are. So you have to ensure that you trust it to authenticate users for you system.
What you could do is to allow for the customer to define its the IDP to be used, provided that the IDP is only allowed to authenticate that customers users.
If you want to do this I would recommend using some third party software.
We're using Microsoft SSO kit version 4.5 (liveatedu) currently to SSO to Office 365. We need ADFS in place before end of this year.
Even though we've installed and tested ADFS + Office 365 in a test environment, its very vanilla. We'd rather users sign in from a customized/branded page hosted in our datacenter instead of the IdpInitiatedSignOn.aspx or the login.onmicrosoft.com redirect.
Most articles on ADFS setup for Office 365 simply end at verifying if ADFS is working. For instance this one. What if we need to tie an existing FBA+LDAP webapp to ADFS so that once signed in, Office 365 is one of the many places the user can go.
This MSDN article looked promising until about half way down it referred to the sign in page residing in cloud, which cannot be branded/customized.
There are several 3rd party companies offering SSO to Office 365 like centrify, onelogin and okta. Where can I find more help on how they achieved it? Any code sample would be awesome!
Setup a SAML IdP or a WS-Federation IP-STS. Customize the login pages of that. Then, add a claims provider trust in ADFS to connect it w/ your IdP/IP-STS. Then, add an RP trust to O365 and friends. Your resulting architecture will look something like this (old drawing that I used for something else, so it's not exact):
What if we need to tie an existing FBA+LDAP webapp to ADFS so that
once signed in, Office 365 is one of the many places the user can go.
Exactly. To do this, your FBA+LDAP webapp must be updated to speak either SAML or WS-Fed. Then, you can connect it to ADFS. (We're doing this exact thing for one of our customers ATM, sans O365. Ping me off the list to discuss details.)
Issues you may run into:
User must select which claims provider to login w/ at ADFS (home realm disco) because you have more than one. AD trust can't be deleted or disabled.
SAML that ADFS wants takes a bit of tweaking and debugging to get right.
If your downstream RP doesn't send a authN context, you will have difficulty inserting it on a per-RP basis before redirecting from ADFS to your IdP. If they do, it will work fine, even if translating between SAML and WS-Fed.
You now have double the certs. How can you reduce this and share the certs between ADFS and your FBA webapp? (Might not be possible or even desirable, but so many issues are due to certs. So, reducing them to as few as possible should be your goal.)
If your down-stream RP has a requirement for some sort of data or authentication strength, you can block access in ADFS w/ an authZ rule. Doing this will require your upstream claims provider to put data in the response that ADFS can use to fulfill this requirement.
Likewise, you can lookup data in ADFS using an attribute store to get additional claims. Helpful if you have access to those databases, but you may not in ADFS.
Anyway, HTH!
I succeeded by trying a totally different approach. I don't need to do this programmatically, at least not in my case. I followed this article basically to configure my "middleman" MVC4 portal as an ADFS relying party. ADFS was already installed in my case which is a large chunk of that article - so I started from "Application side configuration" portion.
Main thing that helped is the Identity and Access tool for VS (msdn)
One thing vankeyenberg's article did not mention was configuring the claims on the ADFS server. Without this I was getting "username null" error when enumerating claims in my MVC4 app especially where I had #Html.AntiForgeryToken(). This is how I solved that: After adding your MVC4 application to ADFS as relying party trust using WIF Federation Utility ("C:\Program Files (x86)\Windows Identity Foundation SDK\v4.0\FedUtil.exe"),
Modify global.asax.cs in relying party (MCV4) to use NameIdentifier claims type in Application_Start as AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
Configure MVC4 app's FederationMetadata.xml to request more claims in the <fed:ClaimTypesRequested> section
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
Uncomment additional claims in the <applicationService><claimTypeRequired> section of the MVC4 app's web.config
Configure ADFS server to send claims requested by MVC4 app
Right click your relying party trust and click Edit Claim Rules
Click Add Rules
Select Send LDAP attributes as claims from dropdown
Give the rule any name, and select Active Directory as attribute store
Add some mappings like UPN, Email address, samaccountname
I have a 3rd party program that supports web SSO using SAML 1.1 (it is ready to serve as the Service Provider, in other words).
We would like to implement this SSO for our intranet users based on their Active Directory credentials. In other words, they've already logged on to their system, so let's simply use those credentials to facilitate an SSO. I am a little overwhelmed at where to begin, though.
My initial thought is that IIS / Active Directory could easily serve as the Identity Provider since IIS gives us "Integrated Windows Authentication" abilities. I would think we could just create a .NET web app that requires Integrated Authentication which simply extracts the current user ID, builds the SAML response, and re-directs the user back to the Service Provider with this SAML response to complete the SSO.
But then, my problem is that I simply have no real idea of how to go about creating this SAML response, the X.509 certs involved, etc... I am wondering if I am in over my head on this, or if creating this SAML response should be relatively easy.
Note this SSO is to be used by intranet users only, so no need to worry about federating with other companies / domains.
Another option that you may want to look into is Microsoft's Active Directory Federation Server (ADFS) 2.0.
I wouldn't bother trying to build something SAML compliant. It will take you weeks to use a toolkit and your efforts will probably only handle the one use case. Once you get something custom into place you'll soon realize the rest of your organization needs some type of SAML integration as well (either internal or externally).
The quickest (and IMHO) easiest way (and you'll come out looking like a hero) is to use something like PingFederate from www.pingidentity.com. You can have it up and running in less than a day if you know what you are doing.
Just my $0.02
HTH - Ian