I have a setup where my application uses Keycloak (version 20.0.2) as identity provider. Keycloak allows also delegating the login to some external IdP that responds with SAML token. I'm mapping the roles in Keycloak based on attributes in the token, which works fine. However, sometimes I would like to reject access for a user (if is does not have any roles assigned) or in some more complex scenario (user can access only if he has some attribute and role combination).
What is the easiest way to do that? Do I have to write my own SPI that will handle that (what kind of SPI?)?
Related
I have an application that includes Keycloak as the identity component. I want to redirect to the Keycloak security admin console for a particular realm from my application, which I am able to do, however I also want to specify a particular IdP to sign in.
For my OIDC apps that are protected by the same Keycloak realm, I am able to do this using the kc_idp_hint query param. However the built-in clients don't seem to respect this, so the following URL does not result in the IdP hint being propagated to the authorization URL:
https://<keycloak>/admin/<realm>/console?kc_idp_hint=<idp>
I have two service providers set up with one IdP and users are required to be authenticated twice to access both services at the same time. From my point of view, this is not "SSO" and I am thinking that there might have been settings done incorrectly and I would like to see if the community here can provide me with directions and/or possible solutions.
Just a thought - the behaviour for the authentication on each service looks valid as I understand that IdP is required to send signed SAML assertions to the providers in order to access the services. However, because I only have one IdP, can I not be authenticated just once and be able to access all the services?
Any suggestion is appreciated. Thanks.
Typically in this scenario the user would authenticate once to the IdP when the first SP SSO's to it. There would be no authentication at the IdP when the second SP SSO's to it as there's already an authentication session at the IdP for the user.
However, there might be use cases where you want the user to be authenticated at the IdP even if they already have an authentication session. The SP can set the ForceAuthn flag in the SAML authn request sent to the IdP. This requests that the IdP authenticates the user regardless of whether or not they already have an authentication session.
ADFS also has a configuration option for relying parties (SPs) to always require authentication. Take a look at the AlwaysRequireAuthentication flag.
https://learn.microsoft.com/en-us/powershell/module/adfs/set-adfsrelyingpartytrust?view=windowsserver2022-ps
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
We are running some tests on Keycloak to implement it on our company and I am are wondering what is the best approach to make Keycloak interact with our legacy system.
In our scenario, we have a native login interface and we are going to use direct grant - we are not going to authorization code flow / redirect flow using a browser and we don't have any kind of social login.
The other point is: we must to keep our native interface.
Based on that, what is the best/right approach to implement this flow? I have set my client on Keycloak with direct grant but the problem is that every user must exists in Keycloak. Isn't possible to use Keycloak as a "token emissor" instead of IDP?
In case of Keycloak must be an IDP, what is the right approach to allow Keycloak log in legacy system? Should I implement a custom Identity Provider? Will mobile make a login request to Keycloak or to legacy system?
Keycloak must somehow be able to either authenticate the user or delegate the authentication of the user to a federated identity provider. A few options:
If you want to use Keycloak as an identity provider, you could do
this by migrating your user base to Keycloak, or by making use of
User Storage Federation, which means Keycloak will use your existing
user database as a source. In this case, the login interface will be
a Keycloak interface (which you can customize to your wishes). See:
https://www.keycloak.org/docs/latest/server_admin/#_user-storage-federation
Another option is to convert your legacy system into an identity
provider that complies with either the OIDC or SAML protocol, and
set it up as an identity provider for Keycloak. In this case you can
keep your existing login interface, but it will probably require
quite some changes to your legacy system. See:
https://www.keycloak.org/docs/latest/server_admin/#_identity_broker
I am creating a service provider which talks to third party IDP for authentication. But I have a concern that I have a set of dedicated machines(Desktop,tab) which are highly trusted, so is their a way in SAML that when a request is sent from such machines user is directly authenticated without the need to type username and password.
you want that user that tries to access a resource from his desktop (which is trusted) will be automatically authenticated? if this is the case, it seems that you need to identify the user using the active directory or something.
if this is the case, search a bit about Kerberos, or ADFS - it might serve your needs.