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).
Related
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.
Our customer is using Okta and is asking us to SAML-enable our app so they can access it using idnetities in Okta.
We plan to use OpenSAML to do it. So far so good.
But usually, our app has access to identities (list of users, groups/members) coming from an on-prem LDAP or AD, for example. We normally use those identities to configure authorizations in our app (give permissions to certain users to access certain ressources). Using SAML only, I don't see how to access the whole list of users/groups. And from what I understand, it's not the goal of SAML to provide it.
How is this situation typically solved? Should we try to sync the identities between Okta and our app? Is it what is called provisioning? There is Okta API, SCIM, JIT, ... Or maybe we should take a totally different approach?
Thank you!
The typical way to handle authorization in SAML is to use a SAML assertion to determine the authorization that a user should have. Which assertion is used and how it is will depend on your authorization model.
Note that using assertions will push the responsibility for determining authorization onto the administrator of the SAML Identity Provider, it will be up to them to decide who has access to what.
The ideal situation for supporting "enterprise federation" is to support SSO and Provisioning. SAML or OIDC for SSO and SCIM for provisioning.
If your software doesn't depend on an up-to-date list of users, supporting just SAML with "JIT" might be sufficient. SAML with "JIT" or "Just In Time" provisioning just means that your SAML Service Provider implementation would add users that it hasn't seen before.
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.
I am implementing Single Sign On through SAML. For this, I need an IDP (Identity Provider) which can be installed on-premise. Can you provide me the list of IDP's available and their licence Cost and supported platform? I searched and found like Gluu, Shibboleth but not finding the exact. Please help me out.
Thanks in Advance.
Refer SAML-based products and services.
I have used shibboleth and simpleSAMLphp - both open source - both work.
If you want to pay, then Ping Federate, ADFS, OpenAM and Auth0 are all good options.
I do not want to share our user identity with anyone else. We are using Progress Open Edge Database to store user id and password and authenticate from there.
Is there any way that we install IDP on-premise where our user identities should not be shared in cloud rather it is in our network?
I am using OneLogin but it allows to share user id with themseleves but i do not want to share user id with any IDP, instead it should be on my network, that is why i am lokking for an IDP which can be installed on-premise.
A little old post but maybe someone else looking for an answer can benefit. There are many Identity Providers available out there. It depends on your use case which one you should go with and if you need an open source or if you want full support for it.
If your use case requires you to support all the IAM features with easy to configure UI then Keycloak and miniOrange are the ones I would recommend. Keycloak is open source and miniOrange charges for support if you need it. There are others like Shibboleth and SimpleSAMLphp but they don't have an intuitive and easy to use UI and you will have make changes in their config files directly.
As you already pointed above since you don't have any cost issues then you can check out ADFS and Ping Federate.
My best choices will be:
Paid : PingIdentity
Free (as in community) : WSO2 IS, Forgerock OpenAM, Redhat Keycloak
Free : SAMLphp, ADFS (you paid for the servers anyway)
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.