I want to design my private cloud with multiple services to make my live eassier. For better usability, I want to be able to login with the same credentials. For that I looked at ldap and openID especially openldap and freeipa. But with FIDO2 coming up and making loggin in way eassier and safer, I wonder if there is a way to use FIDO2 in combination with ldap or openID so users can login with their FIDO2 tokens while having the same credentials for all services.
So in federated authentication there are three parties. Federated Client(The website about Cats), Federated Provider(your mega identity provider) and Authentication Service(the thing that authenticates).
In terms of OIDC, the OIDC Server will redirect to the auth service with a challenge. The auth service will then fetch request info via private(admin) api from the OIDC service, and it then will perform all necessary check, authenticate user and then ask if user wants to allow KittyCats.xyz to use user account to authenticate. If user agrees, the Auth Server will then notify the OIDC Server hat user gave consent, and in response the OIDC server will return redirect_url. The AuthServer will then redirect user to the specified redirect URL.
So in terms of FIDO this is quiet simple. You make a basic FIDO authentication service, then add OIDC logic on top of it and voila, you have FIDO backed OIDC federated authentication.
If you want to play around I highly suggest playing around with ORY/HYDRA. They have a full demo with a mini Auth Service and a wonderful tutorial to get you started: https://www.ory.sh/hydra/docs/5min-tutorial
Related
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 have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
I have a server application, and the clients communicate with this server with a proprietary protocol which operates on TCP. It is not possible make any change to the existing client applications.
Currently the TCP connections are authenticated by the server application, with credentials stored in a database. I need to migrate user credentials to Okta from the database.
It appears that I can use Okta Authentication API in the server application to authenticate users. Also, none of the OAuth 2 flows or SAML doesn't seem to be suitable for my use case.
What is the best approach I can choose to use Okta to authenticate users in my user case?
If your server can see username/password in plain text, and can make http calls to Okta, then you can for sure use Okta for authentication. All you need is a call to /authn endpoint.
Make sure your password/mfa/authentication policies in Okta do not require 2FA and do not expire your password. Otherwise your server would need to be able to process responses from Okta, which would require MFA or change password
We have a scenario where we have to authenticate the user with LDAP server
Flow 1:
client --> application server --> LDAP server
In above flow the client enters LDAP credentials which comes to application server and then using python-ldap we can authenticate the user, straight forward. Since the user LDAP credentials comes to application server an organisation may not be willing for such flow for obvious reasons.
Flow 2:
client --> oauth2 --> LDAP server
Oauth scenario suites best here, since authentication of the user is responsibility of the oauth and application server do not need to know the user credentials.
Have anyone encountered such case, if yes, how you tackled it?
Is there are any Oauth client for LDAP free and paid ?
If you don't want user credentials to reach the Application server then what you need is a perimeter authentication. You need to have an external authentication provider , say Oracle Access Manager, that will perform the authentication and set a certain token in the request. The application server can assert this token and let user access resources. This model enables SSO as well.
The resources that require authorized access are configured as protected URLs in OAM.
When a user tries to access a protected resource he is challenged for credentials.
OAM authenticates the user against an LDAP directory(that is configured in OAM).
A token corresponding to the authenticated user is set in the request. Also an SSO cookie is set.
Application server (Weblogic) can assert (verify) this token and let the user access the resource.
Note: Oracle Access Manager supports oAuth as well.
Ory Hydra https://ory.sh/hydra might be what the original poster was asking for. This question is several years old now but in the interest of helping anyone else who sees this...check out Ory Hydra. It provides the OAuth2/OpenID parts and can be linked to an LDAP server behind the scenes.
canaille is a free and light OAuth2/OpenID service over a LDAP backend, written in python. (canaille developper here)
https://gitlab.com/yaal/canaille
OpenID authentication is inherently browser based. If I wanted to allow an OpenID user to authenticate against an API for use in alternative clients, is there an accepted best practice for that?
So if a user tried to log in with their OpenID into an iPhone app, for instance, how would that work? The only thing I can think of generating an API token of some sort for them and get the user to manually enter it somewhere. This approach is not user friendly.
This is the way sites like Basecamp work, but it still seems clunky to me.
The problem you're seeing is not unique to OpenID. Any password-less authentication scheme can have this problem. OAuth (http://oauth.net/) is a solution that is an open standard that is quickly gaining traction on a lot of web sites. It is totally independent of how the user authenticates, so their OpenID Provider does not need to support or even be aware that your site (the "service provider" in OAuth terms) is using OAuth. Your API client can be web based or even a local application!
The process would be something like this:
Roles:
the user: someone who has an account with your web site.
service provider: your web site, which has a programmatic API that requires some credential to access.
consumer: the client, whether web or local application, that needs access to the service provider's API.
Flow:
The user is at the consumer. He indicates he wants to access data at the service provider.
The user is either redirected (if the consumer is a web site) or a browser is popped up (if the consumer is a local app) and the user sees the service provider web site.
The user is either already logged into the Service Provider via a persistent cookie, or the user must first log into the Service Provider however that is done (OpenID in your case).
The Service Provider then asks the user: "Consumer (some consumer) wants access to your data (or our API, or whatever). Do you want to authorize this? (yes/no)
User confirms, and the browser window closes or is redirected back to the Consumer site.
Via some OAuth protocol magic, the consumer now has a secret credential that it can use to access your API and access whatever user-private information you just authorized.
Obviously I can't include the whole OAuth spec here, but you can see hopefully from the above that this should solve your problem. OAuth libraries exist to make adding support for it easy.
If you happen to be using ASP.NET, I suggest http://dotnetopenid.googlecode.com/ as it recently added OAuth support (v3.0 beta 1).
Neither OpenID nor OAuth define how a user authenticates. They define how the consumer directs the user agent to the authentication provider, how the user agent is directed back, and how the consumer can verify the identity that the user authenticated as.
The actual method used to authenticate is out of band for both schemes.
There are differences between OpenID and OAuth, but both require that the consumer use HTTP redirects and callback URLs. They're both browser based. If your app speaks HTTP, it can do either. However, a main point is that the user is only entering credentials into a trusted app.
What you want is not possible with OpenID. OpenID is based on the premise that you (the iPhone app) only want to know about your users that their OpenID-provider trusts them. They never authenticate themselves to you.
Good OpenID-providers in fact even prevent that you mediate the authentication process (as this would expose users to a possible attack - by you!): they demand that users login with them directly and refuse login-by-referral.
See: this related question
The problem is that the openid spec has no standard provision for authentication with the provider, so the provider can elect that authentication happens via a phone call or whatever.
Hopefully more providers embrace OAuth. Alternatively you could hand code the authentication for a few of the bigger sites.