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.
Related
I'm currently integrating SSO into a web application using passport-saml. Still fairly new to this and trying to understand all the nuances that comes with it so I've got a few questions that I can't seem to find the answer to:
Question 1
I guess, there are two aspects to the IdP side of things. 1 for the customer and 1 for the organisation hosting the SP. So as the org that has the SP, we would need to have our own IdP account to upload our application with all the relevant SAML settings (let's say Okta for this example). The customers would then be able to find the SP from the catalogue of applications from whatever IdP they're using where they can add it and can use the generated Identity Provider Single Sing-On URL and X.509 to input into the SP's settings. I know Okta has a setting to enable their users to find organisation-managed applications which they may need to enable to be able to find our application once approved by Okta. Am I correct in thinking this?
Question 2
Would this mean that as an org, I would need a presence on each IdP a customer might use? OneLogin, Okta, Active Directory, etc.
Question 3
Are IdP's the same for the most part? As in, would I just need to implement SAML into my back end and users can just enter the Idp URL and their certificate, and this will just work for any IdP that the users might be using?
Question 4
Is uploading an application to an IdP a paid service? I've currently got a sample project that is using Okta as an Idp, got all the settings set up but I've noticed that I can submit the application on Okta as a software vendor. Obviously I can't go through it since it's a sample project and I'm also using a trial account so I don't actually know what this entails
Question 5
Lastly, as I previously mentioned, I've noticed that Allow users to add org-managed apps is an available setting for users so they may need to enable this to find my application. But I've noticed that there are thousands of applications that I can browse through on Okta while having this setting disabled. So Okta -> Applications -> Browse App Integration Catalog, I can find applications like Dropbox, etc. Is it a different process (than q5) for an application to be visible on this list?
Question 6
Is SSO at user level or at organisation level? As in, can users of an organisation have a mixture of different ways of logging in? Like, user 1 has SSO enabled but user 2 doesn't. Is that how it tends to work? Or is it more so, an admin enables SSO for the entirety of the organisation whole organisation?
I'm still trying to piece everything together but hopefully I've asked the right questions to properly set this all up but any other additional information you want to share would be helpful!
Answer 1: You are correct that as the organization that has the SP, you would need to have your own IdP account (for example, with Okta) to upload your application with all the relevant SAML settings. Customers would then be able to find the SP from the catalog of applications from whatever IdP they're using, where they can add it and use the generated Identity Provider Single Sign-On URL and X.509 to input into the SP's settings. You would also need to enable the setting in Okta that allows customers to find organization-managed applications.
Answer 2: Yes, this would mean that as an organization, you would need a presence on each IdP a customer might use. Different IdPs have different ways of setting up and managing SP applications, so you would need to create an account and configure your application on each IdP that you want to support.
Answer 3: IdPs are not all the same, but most of them support SAML, which is the standard for SSO. By implementing SAML into your back-end, you can allow users to enter the IdP URL and certificate, and this should work for most IdPs. However, you should check the documentation and settings of each IdP you want to support to make sure that everything is configured correctly.
Answer 4: It depends on the specific IdP provider. Some providers may offer free or trial plans for uploading and managing SP applications, while others may require a paid subscription. It's best to check the pricing and plans of the specific IdP provider you're using to see if there are any costs associated with uploading and managing your application.
Answer 5: Yes, there may be a different process for an application to be visible in the app integration catalog. Some IdPs, such as Okta, have a public application catalog that includes a wide range of popular applications that are pre-integrated with the IdP. These applications may be accessible to all users regardless of whether the "Allow users to add org-managed apps" setting is enabled. It's worth noting that the specific process for making an app visible to users may vary depending on the IdP provider you're using.
Answer 6: SSO is typically implemented at the organization level, meaning that all users within the organization will use the same SSO method to access various applications. However, it is possible to set up different SSO methods for different groups of users within an organization.
For eg. an admin can enable SSO for all users within the organization, but also set up a separate SSO method for a specific group of users, such as contractors or partners. This way, users within the same organization can have different ways of logging in. Some IdPs may offer more granular control over SSO settings than others.
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.
A customer is currently trying to decide if they want a SAML 2.0-based SSO implementation for their application. However, their users have many different identity providers. I have build some SAML-implementations, but they were all for one identity provider only and I don't have any hands-on experience with one application using many different identity providers.
Question: can you generally build one configurable SAML-client for multiple identity providers or do you have to build multiple distinct clients in order to service them all?
A single Service Provider (SP) can use as many Identity Providers (IdP) as it wants. The only thing the SP needs to know is which IdP to use for a particular user. It does that in one of two ways. Either it displays a list of IdPs it knows about and the user selects one, or the user arrives at the SP on a 'WAYF-less' URL. WAYF means Where Are You From but is largely superceded by the SAML discovery process. Providing the entityID of the IdP to the SP bypasses the WAYF, hence WAYF-less URL.
e.g. you could have a URL scheme along the lines of:
https://yourapp.com/login?idp=https://someidp.com/shibboleth
https://someidp.com/shibboleth is the entityID of the IdP. Your SP looks up that entityID in its metadata store to find the SSO URL of the IdP and sends the user to their correct IdP for login.
Once your SP redirects the user to their IdP, SAML flow is normal after that. So the only thing the SP needs to do is work out where that SSO URL is. All the IdPs will return the same SAMLResponse format but with their own attributes etc of course.
First of all I do not have any experience with SAML (version 2).
I was asked to investigate how we can make an existing site, which has a normal login page with a username and password page, ready for SSO with SAML.
There are some tools around which we can use in order to do this.
So I think it is not so difficult to implement the SSO part.
But however it is not clear to me how the authorization is managed.
The system (web site) is using authorization rights in order to determine if the user is able do access certain parts and if he does, the right type he has (view, create or edit).
These rights are assigned to each user by an administrator in the system itself.
When a user logs in the system by specifying his credentials (without SAML/SSO) his rights are also retrieved.
How is this done when a person logs into the site by using SSO?
Is there a mapping of the userId which is know by the IdP (Identity Provider) to the userId which is know by our system?
And is this send in the SAML response from the IdP?
Or is this done in another way?
Thanks in advance
SAML is mainly a authentication protocol but there are still many ways to solve this. SAML supports sending authorization infromation in AuthzDecisionStatement in the assertion.
Another alternative is to extend SAML using XACML which is a big framework for transferring Authz information.
However the support for these are limited in many SAML providers.
The simpler solution and probably the best in your case, if it is just one access right per user, is to send it as an attribute in the SAML assertion. This can usualy be mapped against for user properties.
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.