I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.
Related
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
I'm trying to create a SAML IDP for the system I built. Probably I'm getting confused with concepts. My problem is as follows:
This system was built in SymfonyPHP which authentication is made by OAuth token. Nothing so special, the username and password are passed to the /auth endpoint and the request returns the token if the credentials are valid. It's working fine.
Now I have to integrate this credentials to a client system. Once the user is logged to my system, so it should be on the client side (like the "login with Google button). I've been searching and realized I should use SAML for that.
I installed the SimpleSAMLPHP and I'm trying to understand how to set it up as my IDP. Once it's made, I can create SPs for my clients systems.
Question: how to make the SimpleSAML use my existing service for authentication? Which module should I use?
With SimpleSAMLPHP acting as an IdP, you want to have a look at authentication modules. The latter is a component that encapsulates the mechanics of signing into the identity provider. For example, if you were trying to sign in to the IdP with your Facebook account, SimpleSAMLPHP ships a FB authentication module that does this for you.
If your existing service can be supported by one of the SimpleSAMLPHP modules, then you're all set. Else, you need to develop your own module.
There is an existing mechanism to log into a website. Now, external / remote SAML IDP is being added to facilitate SSO. The website uses other micro-services and components that provide data and functionality to the website.
Is there a way to have an existing mechanism of local identity username password credentials to continue to co-exist as an alternate strategy for authentication alongside remote IDP SSO while keeping rest of the services handling authorization in a semantic way (using a saml token)?
P.S. I looked at the options to implement existing auth mechanism as saml IDP, but building it seems complex even with the likes of shibboleth or openSAML libraries.
P.P.S. I haven't looked at possibility of reimplementing existing auth mechanism with openId connect to co-exist with remote saml idps.
Sure: one can provide a landing page to the user that gives a choice between using a local account or an account at a remote IDP.
ADFS server 2016 supports openId connect. I have external organization that hosts ADFS server , I want my web application to get authenticated from External ADFS server using openIdConnect .
Question : As per Microsoft docs . If we want to consume external organization's ADFS we should host ADFS in our organization also. My application should trust ADFS hosted inside my organization ,instead of trusting external ADFS directly.
Here I want to know why we cannot directly trust External ADFS using opendiconnect ? It seems possible. what is reason of not trusting external ADFS directly?
Both models work. If your application plans to have users from multiple organizations, it is better to have your app trust an internal org ADFS which can then be federated to multiple of these organizations with simple configuration changes. This makes the application simpler where it is dealing with only one IDP. An additional advantage for having an internal ADFS is that any authentication policy changes can be managed fully at internal ADFS layer and not potentially requiring application changes.
However, if your application is only going to support one external organization, you can do this directly in the application. Both models work for this.
Hope that helps.
Thanks //Sam (Twitter: #MrADFS)
I understand that keycloak has built-in clients and we add the users later on.
But in general, what is the difference between a client and a user in Keycloak?
According to the Keycloak documentation
User - Users are entities that are able to log into your system
Client - Clients are entities that can request Keycloak to authenticate a user. Most
often, clients are applications and services that want to use Keycloak to secure
themselves and provide a single sign-on solution. Clients can also be entities that
just want to request identity information or an access token so that they can
securely invoke other services on the network that are secured by Keycloak
In short words, not only for keycloak but for OAuth and OpenId Connect too, a client represents a resource which some users can access. The built-in clients for keycloak represent some resources for keycloak itself.
Clients and users are two completely different constructs in keycloak.
In plain English, client is an application. Example for an application could be a e.g. yelp.com or any mobile application. Client can be a simple REST API. Keycloak's built in clients are for keycloak internal use, But any user-defined application has to be registered as a client in keycloak.
Users are the one which authenticate via keycloak to gain access to these applications/clients. Users are stored in keycloak DB or any externally hosted LDAP but synced with keycloak.