We are considering to implement log on facility using SAML 2.0 on our portal. But is the use of SAML 2.0 increasing or should I use any alternative technology ?
From my organization's (Ping Identity) perspective, SAML 2.0 is still going very strong and likely won't be superseded anytime soon. There are plenty of SAML-based products available - more and more popping up every day. Major SaaS providers like Google and Salesforce have standardized on SAML 2.0 SSO, and we've seen over 1500 others do so as well.
There's some evidence to believe that OAuth 2 based SSO - or most likely OpenID Connect (built on top of OAuth 2) - will eventually become as predominant. At the moment it's mostly focused on consumer facing identity providers & applications like Facebook, Twitter, LinkedIn, etc.
SAML still reigns supreme in the business / enterprise world, where strong trust (federation) relationships are required.
Our school recently jumped on board the SAML 2.0 train. All of our students have access to Gmail for their school accounts. Now we are going to be using a cloud storage service for the students as well, employing SAML again for it. We are the Identity Providers (IdP) and our clients are Service Providers (SP).
I'm specifically using simplesamlphp for SSO generation, but that's merely my flavor preference. Java seems to be the other big platform SAML is used on. Either way, I don't foresee its use in the education industry going anywhere soon.
Related
Recently I have been looking for details about FIDO (uaf, u2f, fido2) and I don't get one point :
Does FIDO will replace SSO ? Or Both would work together ? What to suggest to clients in terms of authentification solution ? etc.
With SSO, we have Identity Manager server. And with fido we have FIDO server.. They have to work together or not at all ?
Please help me to understand.
Many thanks!
Looking for "fido vs sso", "fido or sso" give nothing concrete.
FIDO is an authentication method (with a passkey being the credential name). SSO is an experience, typically leveraging federation to allow sign-in state to be leveraged across multiple sites.
For consumer services, local sign in with passkeys (FIDO2 credentials) can certainly replace "third party federation" (e.g. Sign in with Google, Sign in with Facebook, etc) to reduce dependencies on third parties or to remove privacy concerns.
In work/school scenarios, most applications federate to a central identity provider, giving an "SSO experience". This is often required by organizational policy. FIDO credentials could be used to authenticate to that central identity provider (as could other methods like a smartcard).
Currently my organization uses a number of web apps/mobile apps/APIs, some of which authenticate against an in-house IdP and others which use a third-party proprietary system (over which we have no control).
We have been asked to implement SSO for these web applications and as a result I have been reading up on OpenID Connect. I believe this would be a better solution than SAML given that (a) end-users are not always enterprise users, and (b) SAML not designed for mobile applications.
I believe I understand the flow reasonably well but have one sticking point. To allow users to authenticate using an external IdP, we would need to map the user back to our internal id. For example, user authenticates using OIDC/Google, resulting in us receiving the user's unique Google idenitifer (and email etc if we queried further), but this is not useful to us until we can map the Google identifier back to our internal customer id.
Is this mapping out of scope for OIDC? If so, is there a best-practice method for doing this? I'm sure we are not alone in this requirement...
Thanks,
John
Is this mapping out of scope for OIDC?
Short answer, yes.! If your backend require a comparison/validation with internal identity details, then it has to be done out-of-scope of OpenID Connect(OIDC) protocol. OIDC simply define the process of obtaining tokens (ID and access token), which are required for authentication and authorization.
is there a best-practice method for doing this?
One option is to use out of band directory synchronization. For example, Google provider Google Cloud Directory Sync (GCDS), which allows you to synchronize identity details to LDAP or MS Active directory. Other alternative is to use SCIM protocol to communicate and provision users dynamically. For example Google provide that support as well.
Alternatively, you can use just-in-time provision at the time you receive tokens. This support will depend on your identity provider implementation. For example, WSO2 identity server support both JIT provisioning as well as SCIM.
Looking for direction.
I've got a single web application that I want to SSO into from multiple applications that all handle their own authentication. The web application wants to use SAML for SSO'ing. The web application requires IdP metadata (we've got one web service that is its own IdP, don't know what the other applications are using). The web application can also accept SAML Assertions with provisions to determine user access when it creates the new users after they SSO in.
I'm looking to get a one stop shop for the web application to hit to determine authentication and authorization.
I've got another web application (.NET Core) that runs Identity Server 4 to handle authentication for one of the many applications that wants to SSO into the web application. Can I use that? I would need to integrate SAML into it. How do I do that? Also, how can I easily integrate all the other applications to use this one web application to SSO into the SAML web application. Is this what Federating is?
Trying to do this with minimal work to all the other applications because that kind of integration work across multiple teams would be kind of a nightmare.
Any suggestions?
Thanks!
If you're already using Identity Server 4, you're probably best to stick with it and add SAML SSO support to it.
SAML SSO support isn't included natively in Identity Server 4 but there are two commercial offerings that add this support.
The following link has some good articles describing how to support SAML SSO in Identity Server 4.
https://medium.com/the-new-control-plane/tagged/identityserver4
Say I'm a small application (www.example.com) and I'm integrating with a much larger enterprise (www.acme.com).
In this scenario I am the service provider and they are the Identity provider.Their request is that I integrate into their auth ecosystem using SSO (specifically SAML 2.0).
For the standard IdP-initiated flow, users will sign in on their end and they will POST an XML assertion to my application, which will then verify the user and sign them in to my application (i.e. set a browser session).
The enterprise uses PingFederate as their identity server, and they are curious what implementation my application uses. At this time I have none.
If my application is a single monolith (e.g. a small Ruby on Rails app), do I even need a federated server? Ultimately they are just looking for a place to POST SAML data to, so I can set up an endpoint and go from there right?
What are some general benefits of a federated server? Why wouldn't every service provider application (small and large) just set up an endpoint to ingest SAML data and call it a day?
Thanks!
You don't necessarily need a Federation server. However, if you decide in the future to divide/expand your application into micro-services or integrate your service with other 3rd Parties, a server will allow you to scale without disrupting your current customers (great CX) and not have to manage separate security endpoints.
I think we should move this to software engineering
How do users authenticate with your service? Having a federated identity guarantees that the whole user management process it's someone else's problem. They're looking for a way to integrate your service into their authentication system, so you need to set up an endpoint not only to consume but to be able to send SAML request to their identity server as well.
I use my Google Account credentials to access almost all my social networking sites (including Stack Exchange), that means among other things that all sites know me as the same entity plus I just have to remember the one password.
Don't know about SAML but almost everybody is using OpenId or OAuth.
I have some some basic questions on Openid
1. Can anyone become an openid provider?
2. If someone signed-up to our site will they be able to use that id in any other website that uses open id ? example Google aps ?
Most sites that do OpenID are just consumers. If you become a provider, you dictate who can become a consumer. Many sites are only configured to accept specific OpenID providers, but those that accept any OpenID provider (e.g. SourceForge) will work with your provider.
For Google Apps, this post may be useful:
How do you delegate your OpenId to Google Apps
Sounds like you have to pay Google money to get access to that feature but a lot can change in three years.
If you are just looking for a generic SSO system, I recommend looking at:
http://barebonescms.com/documentation/sso/
It is "consumer-only" for the moment.