I wrote a theme for a keycloak in ftl. in several places I use ${client.baseUrl} as a return to the login page, unfortunately after clicking this link clientId changes to account and not to the correct client in the context of which login is taking place.
I will add that I use rootUrl and baseUrl the same in my client as in the client account. Does this cause a problem with losing client information?
How can I solve this problem?
Related
Actually the magnificent piece of software called backpack for laravel cannot handle natively the 2fa auth, for now, at may of 2022.
We would like to add to your project this package: https://github.com/thecodework/two-factor-authentication
To be able to integrate with backpack for laravel we must override the login controller of backpack
How can we do it?
As much I would like to have everything integrated with Backpack, unfortunatelly time/money/tech does not allow us to do that. I really hope sometime I can dedicate more of my time to this "goodies" (2fa, graphQL etc etc).
For now, we've just added a simple way for people that don't want to use the default backpack auth to disable it and implemente their own auth mechanism if needed.
https://backpackforlaravel.com/docs/5.x/base-how-to#customizing-the-auth-controllers
Don't stop on this tag (customizing the auth controllers), later down on that page there is more info about auth that could help you here.
If you need my help with something you know where to find me.
Cheers
We reached our goal overriding LoginController and ResetPasswordController of bakcpack.
To be precise: after a succesfull login, we immediately logout, send OTP code via sms and redirected to form we ask for this cde.
Then, posting the code, with an hash in the db, we can check both user, hash, token and validity of token.
If all valid, we actually login the user
For password recovery, after changing password, instead of redirect to home or similar we logout and redirect to login so user can do a login without bypass otp
I am building a flutter app that needs the user to authenticate against an identity provider in order to user the app.
I am using the package simple_auth_flutter to do the authentication stuff. So far this works as expected: When clicking on the log in button, the users is queried for its credentials and after passing the correct credentials I get a valid token.
I only got an issue, when the user logs out from the identity provider. When the user clicks on the log in button he gets automatically logged in without querying for the current users credentials.
While logging out I delete the token from within the package and I revoke the token on identity providers side.
Any idea what could be the reason for this behaviour?
OIDC based Identity Providers issue a session cookie when you login. This is what enables single sign on across multiple apps.
To force a new login prompt, logout typically needs to send an End Session Request so that this cookie gets removed.
My Android sample code does this, though I am using different libraries. Not sure if Flutter has end session support?
Also worth being aware that some identity providers require vendor specific messages.
I had the same issue with my flutter app using Firebase and Microsoft as identity provider. I solved the issue by using the "prompt" parameter within the authentication request. Below you can see my code for oAuth authentication with Microsoft.
await FirebaseAuthOAuth().openSignInFlow(
"microsoft.com",
["email openid profile offline_access"],
{
'tenant': 'your tenant id',
'clientId': 'your client id',
'prompt': 'login'
},
);
Also see the Microsoft documentation where the "prompt" parameter is described in detail with all the supported values (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc).
Fixed
When you logout on Firebase you are only clearing the app's state not the browser. One possible solution is to check if your provider offers a logout endpoint which you can call in your app during logout to invalidate the browser cookies. Microsoft is an example of a provider offering this.
The user data is attached with the provider session.
https://docs.microsoft.com/en-us/azure/active-directory/azuread-dev/v1-protocols-openid-connect-code#send-a-sign-out-request
BEST SOLUTION:
User? user =
await firebaseAuthOAuth.openSignInFlow(provider, scopes, parameters);
Make sure parameters has a prompt key with an applicable value mentioned here: Fixed:
User? user =
await firebaseAuthOAuth.openSignInFlow(provider, scopes, parameters);
Make sure parameters has a prompt key with an applicable value mentioned here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#send-the-sign-in-request
The only one I got to work to an acceptable criteria is:
'prompt': 'select_account'
My provider, scopes, and parameters:
'microsoft.com', ['email'], {'prompt': 'select_account'}
The only one I got to work to an acceptable criteria is:
'prompt': 'select_account'
My provider, scopes, and parameters:
'microsoft.com', ['email'], {'prompt': 'select_account'}
I'm trying to integrate Okta as a third party Identity Provider for a system I am working on that is using the IdentityServer 3 framework to support my customers that use Okta. I have everything working great except log out. When a user logs out of my system, it initiates the end session call back to Okta to log the user out. My problem is that the Identity Server is sending a session id along with the post logout redirect uri for context, but Okta refuses to accept the redirect uri because it is not known. I've tried multiple variations in the setup in Okta for this url but because the id value is dynamic, i'm not able to specify an exact url. Is there a way to have it support any urls that are going to a specific hostname or even up to the page path? I've tried adding my host into the API security area for trusted origins but it did not work either. I've also tried overriding the postback url for my system to be a static page, but then the IdentityServer Signout message cookie is never cleaned up correctly. This same code works without any problems when running for Azure as the IDP. Has anyone run into this before and have any thoughts? Any help is appreciated.
An example of the post to Okta at signout with the postback url is something like this,
https://dev-xx.oktapreview.com/oauth2/default/v1/logout?post_logout_redirect_uri=https%3a%2f%2fmyurl.com%2fidp%2flogout%2f%3fid%3d83617adbc6769e5d4d0fbca4dced3991&max_age=5&id_token_hint=eyJraWQiOiJ1aXJYc1RYTkTVVGenBXU1JfMWt6WndNSXBQQUVqT0dndWhjbloxR3pNIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHU4eTlrajNyT2NreW11cTBoNyIsIm5hbWUiOiJKYW1lcyBSZWFtZXMiLCJsb2NhbGUiOiJlbi1VUyIsImVtYWlsIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsInZlciI6MSwiaXNzIjoiaHR0cHM6Ly9kZXYtNDg5MDgyLm9rdGFwcmV2aWV3LmNvbS9vYXV0aDIvZGVmYXVsdCIsImF1ZCI6IjBvYWVvdXMycWFJTWJ3U0dhMGg3IiwiaWF0IjoxNTM2MjQ5NzY2LCJleHAiOjE1MzYyNTMzNjYsImp0aSI6IklELlVUem5sTC1FRUY0aHFoZlNSbG5wV1cyUGRxQzlBRk1PcDZiOTh6UERRUUEiLCJhbXIiOlsicHdkIl0sImlkcCI6IjAwbzh5OWZycXVmOFlpaG50MGg3Iiwibm9uY2UiOiI2MzY3MTg0NjU0NTA1NzI4ODQuWldOaVlqZG1aamt0Wm1Fd01TMDBNVGc1TFRreE4yTXRaR1kzTWpreVl6ZGpOekprTm1GbU16WTJaRFl0TURBeE15MDBNMkUwTFdJM01ERXRNek5oWTJOaU1qZ3daamd4IiwicHJlZmVycmVkX3VzZXJuYW1lIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsImdpdmVuX25hbWUiOiJKYW1lcyIsImZhbWlseV9uYW1lIjoiUmVhbWVzIiwiem9uZWluZm8iOiJBbWVyaWNhL0xvc19BbmdlbGVzIiwidXBkYXRlZF9hdCI6MTUyMzYyNjUzMiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImF1dGhfdGltZSI6MTUzNjI0OTc2NiwiY19oYXNoIjoiMWoxa1JTSGhObGRGWGNmSDdCQXRBUSJ9.gvG_8dnlAMr9XI-atCjIKVF04L4oMzerXmeT0BAG76RLle-q2pgb8PDvV4cTicLH16QLzboSgocC6t6WoegbUeJLLuzZHd2rQkm8Y4iRheoV05uKhd2mpLA9LyexlJ9oVJ8Xi_D4BqN_bygphAv79B4L8-Ezz3YgGDmSkK3WutB55_r_7XM0OCCCetvNu4S8KXbKHUxgg5cpQ6y7o-d5eIH6I8bpoOoA0gy7Liwsm7IyQUe5_jdorObgBHIEfDx4mjNRENJUQ7InASwbL7eND7COZYyXRwzn7vHU0_XkBaUW9wsY-VJUaihOwEcgVS1MPbGLoSUY9k0TmcUVN3-Q&state=83617adbc6769e5d4d0fbca4dced3991&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554
the id=83617... is what is tripping up Okta from trusting the redirect url. I've tried adding all of these combinations of urls into the logout redirect uri setup and none let it accept it,
https://myurl.com/idp/logout/
https://myurl.com/idp/logout/?id=
https://myurl.com/idp/logout?id=
https://myurl.com
https://myurl.com/
https://myurl.com/idp
https://myurl.com/idp/
https://myurl.com/idp/logout
None seem to work.
How to disable username/password login for external IDP ?
I know that I can use custom theme to hide http form, but I want to do it properly.
As far as I know I have to create at least custom First Broker Login and Browser authentication flow, right?
After first login from IDP I have to create user in Keycloak, but do not leverage password option.
Also Browser flow must be updated to not show username/password form, right?
Can anyone provide proper example ?
Thanks
You can use a custom authentication provider to achieve your goal.
Instruct Keycloak to assign a specific user attribute to all users arriving from the IDP.
Build an authentication provider which checks for that user attribute and denies access.
Add the authentication provider to the Browser login flow.
Optionally adjust templates files to hide login fields and show a user-friendly error if the user fails step 2.
Further details here: https://groups.google.com/g/keycloak-user/c/N9cuqXIBrSA/m/sycLxTZbCAAJ
May not be 100% suitable to this case, but found next one working fine for our case without need to compile and deploy "custom authentication provider". In our app we suppress keycloak login form and offer own custom user / password form, and for IdP integration we are using kc_hint to redirect directly to IdP login page. Once user login via IdP we want to disable user name / password login using password grant. There is a trick allows to achieve this in keycloak v15. You can assign "Update User Locale" to "Required User Actions" of the user, from that moments, direct password grant wont let user to login returning "requires action" validation error, which is not supported in our UI, while IdP login still works and skip this "required action" nor reset it after login. Of course you may need some scheduled curl script allows to set this for users automatically via users REST API : read users attributes or IdP link integration, if found specific Idp related user attribute or IdP integration link, and "requires action" array is empty, set it to "Update Locale".
Of course this all works as long as you hide keycloak login form and use your own. for all using keycloak login form, login using name / password will work and can bypass "Update locale" requirement (not sure why, perhaps because realm does not have locales configured)
Try this costum Authentication flow
By Automatically linking brokered account, the user won't have to set a password. as for the username it will be automatically imported from the identity provider.
We have SPA, IdSvr3, and a third party IdP(AAD B2C).
The user authenticates successfully. When the user clicks an edit profile link in the SPA, they are directed to IdSvr using the authorization_endpoint. I pass in an acr_value called "profile."
I believe this is the same problem as this gentleman- https://github.com/IdentityServer/IdentityServer3/issues/2816#issuecomment-217161898
I've tried a few things:
Implemented ICustomRequestValidator.ValidateAuthorizeRequestAsync.- In this method, I retrieve the acr_values. There doesn't appear to be a good way to direct the user from here. There is the RedirectUrl on the ValidatedAuthorizeRequest that does redirect the user, but all the information on that object is from the client request to IdSvr and is not relevant to the IdP.
Perhaps there is a setting on the ValidatedRequest that could be tweaked to force IdSvr to direct over to the identity provider(in this case the IdP is - Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthentication)
Implemented a UserService. If the user is logged in, the events trigger IsActiveAsync and GetProfileDataAsync. In IsActiveAsync I can get the acr value from the HTTP context, and set IsActive to false, forcing IdSvr to go back to the IdP. I can't access the context from OpenIdConnectAuthenticationNotifications.RedirectToIdentityProvider, so I haven't found a way to access the acr value there. Is there a way to pass something into here to check if this should be an edit profile?
Similar to the UserService I've implemented IsAuthenticationSessionValidAsync to invalidate the session and force the idsvr to direct to the Idp. This has the same issue of not being able to access the acr value.
PartialLogin doesn't appear to be the right strategy for this either because it appears to only be triggered from a user who isn't authenticated yet. Perhaps if we force the user to log-out, this could be used to direct them to the IdP? https://identityserver.github.io/Documentation/docsv2/advanced/userService.html
Logging the user out feels like the wrong approach to begin with, but it seems like it could be made to work.
Is there a standard way of intercepting a request and directing it over to the IdP based on something in the request?