I am trying to onboard users from an organization that uses an ADFS server to our web app. But we do not have an ADFS server of our own. Hence we are unable to take advantage of the federation metadata. So we had our wepapp setup as a relying party and we have an identifer.
For logging in I have been using the ADFS IdpInitiatedSignOn page like the following:
https://adfs.ogdomain.com/adfs/ls/IdpInitiatedSignOn?loginToRp=our-identifier and this works.
I have found this idea here. Now, are there any other ways to obtain the login URL of that ADFS server for my identifer using only the identifier? or is it the only way to do it for those who do not have an ADFS?
Related
We maintain a website that uses the built-in .NET Core / EF Identity model so all user data is in DB tables. We now have a need to support SSO into another 3rd party system which requires that we host our own IDP with support of SAML 2.0. We don't want to change our identity model or login process for our own website, we just need to return a SAML Response for a user without our website as a response to an SSO request by the 3rd party website. Our site is hosted in Azure as a Web App but we don't use Azure AD for this website which is public facing for external client employees.
Are there any recommendations to create a simple IDP that maps to our existing AspNetUsers database table to retrieve and prepare an SSO Response but doesn't impact our existing identity setup? In all likelihood, we'll have to support other SSO protocols in the future with the same implementation. Do we need to go as far as to implement IdentityServer4, making the existing web app act as both an IDP and a client app?
idsrv4 supports the EF identity model (AFAIK). If it doesn't you could always write your own plugin.
idsrv4 then becomes the IDP and will authenticate against your current DB.
idsrv4 has SAML and WS-Fed plugins to support future SSO.
Your other choice is to implement something like Auth0 that supports authentication against local DB and has full support for SAML and WS-Fed.
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.
I am tasked with setting up Single-Sign-On between ADFS and Taleo Business Edition. In this case it is an IdP initiated SSO and I have to use .net. I know .net 4.5 supports SAML, which is what the relying party (Taleo) requires to validate a user-- but I cannot find any good tutorials to even get started. Any help is appreciated, I have read through the WIF documents and some of their Developer Training Kit but it does not seem to be what I need to do. Does anyone have any pointers on good places to start? No one in my office is sure of how to do this.
EDIT: My approach is to just create a .aspx form and put that link on our intranet homepage, send the necessary credentials to the relying party (Taleo), who then interprets the SAML token and redirects the user. Does this this seem like a sound approach?
What you have to do is add Taleo as a Claims provider to ADFS. easiest to ask then for their metadata file and import that.
Essentially you are federating ADFS and Taleo.
This a common pattern - refer e.g. AD FS 2.0 Step-by-Step Guide: Federation with Shibboleth 2 and the InCommon Federation for a SAML example.
.NET 4.5 does not support the SAML protocol - it only supports SAML tokens. Neither does WIF.
You would normally go to the ADFS IDP Initiated page, sign in and then pick Taleo from the dropdown and then you will be redirected to Taleo with SSO so you won't need to authenticate again.'
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.
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