We have a server that is going to have different web applications for different clients.
I need to be able to secure one web app with one IdP, and another web app with a different IdP. Sich as below:
"my.host.com/webapp1" with thier.IdP.com
"my.host.com/webapp2" with thier.IdP2.com
How do I configure this? I'm assuming I need to do something in my shibboleth2.xml. But I'm confused where I'm supposed to secure one path and tie it to one IdP.
I think it's implied, but these are 2 different customers and there should be no sort of cross talk (i.e. using one IdP doesnt allow you to to get into the other web app, and vice versa).
I'm assuming I need to do something in my shibboleth2.xml.
Your shibboleth2.xml should contain references to multiple IdPs probably through ApplicationOverride stanzas.
I need to be able to secure one web app with one IdP, and another web app with a different IdP
Your Apache HTTPD configuration should direct the user to the correct Shibboleth EntityId based on path. For example:
<Location /customer/aaa>
AuthType shibboleth
ShibRequireSession On
ShibRequestSetting entityId https://idp.customeraaa.com/idp/shibboleth
require shibboleth
</Location>
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.
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.
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.
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 want to deeply integrate OneDrive with our web app in order to handle document and storage data. However, we want the users not to log in twice. I'm not sure whether this is possible, but I've been reading about SSO and SAML and it seems like it's the way to go.
Is it possible, and if so, is Single Sign On the way to go?
Single Sign-On (SSO) is a great solution for user experience when web applications are hosted on different domains. SAML as a standard was developed for cross domain authentication to solve this use case. You will need an Identity Provider (IdP) server that handles authentication of users to your web application and then the IdP Server issues SAML assertions to your web application and OneDrive. Your application in this architecture will be a Service Provider (SP) that will consume SAML assertions, as well as OneDrive is a SP that consumes SAML assertions. There are a number of SSO/Federation vendors that provide the IdP Server.
As far as implementation, once you have chosen and installed the IdP Server, you will need to implement your web application to consume the SAML assertion and configure the IdP Server as a connection. OneDrive will simply be a configuration as it already supports SAML and WS-Federation.
In addition to SAML as a protocol, there are other standards with respect to SSO/Federation such as OpenID Connect (OIDC) and OAuth2. When choosing a IdP Server solution you may want to look at these other protocols that can solve additional use cases. SAML works well for web applications and the use case you have described. OIDC and OAuth2 are better suited for secure APIs and native mobile applications.
Another consideration when looking at an IdP Server is how authentication is to be performed. Options for authentication could be using Kerberos/IWA if all clients are on a common domain, or authentication using a Login Form. You may also want to look at MFA support when looking at an IdP Server as part of the SSO solution.