I have an application that uses Spring Security LDAP for User authentication.
What I'm trying to do is build a feature that requires the User to provide their password again for validation of credentials before performing an important process.
The user is already signed in, so I wouldn't want to kick the user out by killing their current session.
This sounds like it could be a tricky requirement to fill. I have one somewhat outside the box solution that could meet the requirement:
Create a sister Grails application that uses the same Grails/Spring Security/LDAP structure as your primary app.
Expose a /verifyLdapCredentials Service in the sister application to accept the user's LDAP credentials
Authenticate against LDAP
Sends a success/failure response back to the primary application
Unauthenticate from the sister application immediately to prepare for the next request
I ended up creating a separate service and controller to make a simple LDAP auth and lookup.
The service would login with the Spring config settings, then apply the username and supplied password and validate CN result.
Related
Iam using Moodle 10+ and I have done a manual enrolment for an user and also try using 0365 integration (oidc ) for the same user. Integration is done successfully and also syncing as expected. Using Active Directory sync user is matched and 0365 record is created successfully.
Now the problem is that it appears that every user can have only one authentication enabled. I wish users can either use manual authentication or Oidc to log in to their account.
Anyone has successfully implemented two authentication for a same account?
It’s throwing error when logged in using oidc for a same user who’s auth field in mdl_usr is set to manual. If I change to oidc he can’t login using manual.
Is there any solution for this?
Thanks in advance
You can only have one authentication method per user.
https://docs.moodle.org/311/en/Authentication_FAQ#Can_a_user_have_more_than_one_authentication_method.3F
With manual authentication, the password is stored in Moodle.
With OAuth2, the password is stored on the remote server.
So you can't mix them.
How do I best configure Keycloak so that a user needs to have an account for a client to be able to login into that client?
I have to replace a proprietory SSO-Impl. It deals with users, roles and clients much like Keycloak. However, it also knows about accounts. A user is only allowed to login to a client if he has an account for that client.
In Keycloak, if a user simply exists in a realm he may login to a client of that realm. Nothing else is needed. So no "account" is needed. In the old application, he needs an account as well.
What functionality in Keycloak is best suited to overcome this difference?
I have one idea:
Create a client-role in each client namend "HasAccount" and assign it to users. Then, restrict access if that role is missing.
This is discussed here: "Restrict client access in a single realm with keycloak"
It has at least two drawbacks:
It mixes authentication and authorization in the legacy app. I can understand that. But creating a role was already a workaround. That is why I described my initial problem here.
I have clients in 3+ languages/technologies. Adding functionality there seems like more work than in Keycloak.
Last remark:
Before you ask "This is not single sign on" anymore. It is only for administrative purposes. The admin can allow users to login into a client or not by creating an account or not. The user does not have to login a second time. If he is logged in in App A and has an account for App B, accessing App B works without logging in there.
A user is only allowed to login to a client if he has an account for that client. is really not a task for Identity Provider (IdP). It provides only identity and not authorization.
Of course you can ignore that and implement authorization as well. See: User attribute based web service access control by Keycloak
From the design perspective I would add auth reverse proxy in front of legacy app (but it isn't a best solution for SPA apps). Auth proxy will provide authentication via OIDC protocol and also authorization. Legacy apps may keep own OIDC authentication - it will be seamless auth from the user perspective, because SSO will be used.
Account entity - you can use group entity in the Keycloak instead of original account.
If I am provided with a valid userId in the backend, I want to obtain a valid session inside Keycloak for that user and bypass the manual authetication process -> redirecting directly to the home page of the web app.
Is this possible in any way?
Sounds dangerous but you need to create a custom Authentication flow and only have the Username Validation execution
https://www.keycloak.org/docs/latest/server_admin/index.html#_authentication-flows
I'm looking to use an identity service such as Azure B2C, Auth0 or OKTA to secure my application.
After the user signs up for an account, I need to display a custom registration form in my application in order to complete the registration. This form requires a business process behind the scenes and therefore it can't be part of the Identity Service (IDS are quite limited to capturing static data).
How do I ensure the user has completed the registration form on my application, when they sign in?
I'm thinking of using a claim such as "RegistrationComplete" and setting this to False when the user signs up. After they've signed up I can update this claim to be True.
I can't find any information online about this scenario so I not entirely sure its standard best practice.
Disclaimer: I work at Okta
Okta does have some features which should allow this. You can pull properties from the user's profile in Okta and put those properties on tokens as claims when the user is authenticating. So the user profile holds the state you care about. Your app/service can then read this claim from the token to determine if the form should be shown. Once the form is complete, your backend service can use the Okta APIs to update this user profile state, and then send the user through the authorize flow again to get a new token with the updated claim (specifying to not prompt for re-authentication when going through the authorize flow again).
There is a restful provider feature in azure ad b2c. Using the Rest Apis from any service along with custom policies in b2c, we can get user input and save that user input to any database. The REST apis can be used to orchestrate any step.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom
From the Valance documentation it looks like the user is always required to enter credentials at the D2L site. Is there a way for Valence to be used, without the user re-entering credentials, when a user is already authenticated by the originating webapplication? Is some type of SSO available?
Yes, In the typical configuration for SSO between a web app and the Learning Suite the same authentication service is used (either the Learning Suite itself, or a separate authentication service , or possibly the webapp that is calling in is also acting as an authenticator in the case of a portal). If any of these scenarios apply, SSO will work as follows:
Authentication is done within the browser so if the user is authenticated already and goes to the authentication service it will already have the session cookies associated with the authentications service. Therefore when the auth step is triggered it will be pass through -- meaning the user is not prompted for credentials (on the first use the user will be prompted to allow access to this app).
Additionally note that Valence APIs do not use session tokens that are subject to hijacking and instead uses ids and keys (http://docs.valence.desire2learn.com/basic/auth.html) that are used to perform signatures. As a result those keys are long lived. Apps do not need to reauthenticate the user to the LMS if they still have keys from a previous execution of the app (these keys will be reset in certain circumstances so callers must be prepared to respond to a reset key). As a result you would not typically reauthenticate a user to the Learning Suite every time the user has a session.
(if the above does not apply other SSO scenarios may possible)