I have the following question about fusionauth. Is this service itself an identity provider or is it necessary to configure an external identity provider such as OpenId or SAML?
FusionAuth is a complete identity provider as well as a service provider. This means that you can store all of your users in FusionAuth and have them authenticate directly.
You can also use FusionAuth to log users in via other IdPs such as Google, Facebook, Twitter, GitHub, Active Directory, etc. This is called federated login and FusionAuth will handle reconciling user accounts.
Within FusionAuth, you can create an number of Applications, which are just resources a user can log into. Using FusionAuth as the identity provider via OAuth, OpenID Connect or SAMLv2, you get single sign-on for free. The UI for FusionAuth's login pages are also themeable, so you can make it look like your brand easily.
Finally, FusionAuth provides a complete authorization system as well. Each Application can define any number of roles. You then create a UserRegistration, which is a User, an Application and zero or more roles the User is granted for that Application.
Feel free to check out our documentation here: https://fusionauth.io/docs/
It provides a bunch of detail on all of these pieces.
Related
We have a SPA web application that supports OpenID Connect login from external Identity providers. Our application supports different user types (roles). We want to support Sign in with Google using Google Identity service (https://developers.google.com/identity/protocols/oauth2/openid-connect) but the Access Token seems to be for Google APIs only (we want to protect our own APIs). The ID Token is a JWT we can validate, but there is nothing in the claims we can use for Authorization.
Is it possible to add custom claims to the Google ID token that we can use for Authorization?
From the link above...
This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified
I guess this means they ONLY support Authentication and not Authorization? Is this true? Or is there some other Google service we need to use to get user roles (Google Cloud IAM, etc.)?
How does Google expect us to Authorize users they Authenticate?
To get control over what the tokens contains, then my recommendation is to add a separate identity provider in-between your applications and Google. In this way, your applications only need to trust your local provider and it can provide the tokens that you need and you can add additional user information/claims to the tokens.
Just like this picture tries to show:
I'm trying to do limit access to my application using WSO2 identity server.
In summary, a contracting company will send us a list of authorized usernames and, using WSO2, we want to be able to federate access and authorize only those usernames into each application of ours.
The general setup is: my WSO2 server will act as a federation hub to various external identity providers (IdP). These IdPs will contain their own user tables with all the users of their third party company. However, only some of those users should have access to our application (to charge by user count), as demonstrated by this diagram.
So far I've been able to
login into the application using WSO2;
Federate authentication from WSO2 to the external IdP; and
I'm able to restrict access to the application with XACML policies based on the user's role.
However, all the attributes currently come from the external identity provider, so in this scenario, they would actually be in control of who has access to the application. What I want is to be able to use their IdP for authentication, and my WSO2 instance for authorization.
Could you shed some light on how to achieve this?
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
I’m reading the “Learn the Basics” article on Auth0 here. It talks about how Auth0 sits between the identity provider (such as Facebook or Google) and the app. The identity provider provides users to Auth0, which in turn provides the same users to the app. The difference is that while the details of the connection between the identity provider and Auth0 depends on the implementation of the identity provider, the details of the connection between Auth0 and the app stay the same, so Auth0 provides users to the app while hiding the details of the implementation of the identity provider from the app. My question is: is this the main point of Auth0? To successfully receive users from the identity provider no matter what the identity provider’s implementation and then forward the users to the app in the same consistent way every time?
Auth0 provides many different features. It can act as the service provider like you describe, or it can act as the identity provider and host the user data. In addition to issuing tokens after authentication, the platform can provide features like role based access control, M2M authorization, and custom hooks and rules based on authentication events. In addition, other features such as multi-factor auth, password reset, email verification, can all be achieved in a turn-key manner using Auth0.
Should be a simple matter of registering the app in the IBM Cloud and providing callback URIs for authenticating the user and returning control just like login with google or login with Amazon.
But I cannot seem to find the exact flow of steps involved.
--prasanna
I think the service you are looking for is App ID.
When you are developing a web application, you can use the App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.
App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code exchange step the tokens are always sent via a secure backchannel between the app and the OIDC server. This provides an additional layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.
App ID interacts with identity providers by using multiple protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory External link icon or Active Directory Federation Service External link icon, generally use SAML as their identity protocol. For Cloud Directory, the service uses SCIM to verify identity information.
Read this blog post for using a custom identity provider
For an in-depth understanding of the flow, you can refer to this link