In Okta, I can unassign a user from an application but then the application will not know that the user has been unassigned and will still show the user in the application.
What is the best way to "alert" the application that the user has been unassigned so that the application can remove the user appropriately?
I looked at event hooks but event hooks send out a user unassigned event hook when the user is unassigned from any apps. I want to send a specific event hook out to the external application specifically for that application so that application can remove the user accordingly from their side.
https://help.okta.com/en-us/Content/Topics/automation-hooks/event-hooks-main.htm?cshid=ext-event-hooks
I see I can also download reports (recent unassignments) but that is a very manual process.
Is there an api endpoint I can hit from the external app to compare the users?
What do you suggest?
The best option is to use SCIM provisioning mechanism, where only events related to a particular application will be sent out to your configured endpoint on the application side.
Please check out Okta SCIM documentation
Related
Can I assign specific event hooks to specific Okta applications?
I created a user is unassigned event hook but I'm receiving the event hook request when the user is unassigned from all Okta applications.
I would like to send out specific unassignment event hooks to different URLs depending on which application the user was unassigned from. So I would like to attach specific event hooks to specific applications so that the external applications can handle deprovisioning on their side.
Is this possible?
Looking through the documentation, it does not appear that is possible
https://developer.okta.com/docs/concepts/event-hooks/
Okta has open beta in progress for "conditional hooks" where you can filter events to be delivered to the hook endpoint. It might be something you can use to configure multiple hooks of the same type but different URLs for different applications based on the filter expression.
Check you Settings -> Features -> Open Betas if you have it
I am using Okta for SSO and I want to receive an event webhook for when a user is assigned, deleted, removed from an application.
The Okta documentation says there's 2 types of hooks (asynchronous and synchronous).
I think synchronous, inline hooks are better because if my backend app doesn't process the event correctly, then I do not want the user to be removed on the Okta side.
Which inline event hook type should I use to know when a user is removed/unassigned from an application?
Documentation I have looked at so far:
https://developer.okta.com/blog/2020/07/20/easy-user-sync-hooks
https://developer.okta.com/docs/reference/api/event-types/#catalog
https://developer.okta.com/docs/concepts/event-hooks/#sample-event-delivery-payload
https://developer.okta.com/docs/concepts/inline-hooks/
https://developer.okta.com/docs/reference/hooks/#get-started
Sync hooks exist only for certain events, so you can't just choose for any given event which hook you want to use. If I'm correct application unassignment is not the one covered by inline hooks, so you are left only with async one.
You can read more about inline ones in Okta documentation
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I have been experimenting with the REST API using my logged in user account's token to then make PUT requests on my user record to update some custom attributes.
In order to get to this work I had to grant my user account the manage-users role in Keycloak, prior to this I was getting forbidden responses back.
I can now make the PUT request successfully, and after logging out and logging back in I can see the updated attributes I set in my PUT request.
But I have now allowed my user to be able to manage all users in my realm, which I dont want to allow.
Instead I only want to be able to update my own account details.
I know the user can view their own profile and make changes on the Keycloak provided screens. But for certain custom attributes I want to be able to do this from the client side application they are logged in to, so using the REST API but not granting them a role that could allow them to update other users details.
Is this possible?
According to the User section Keycloak's Admin REST API, this is not possible.
One solution would be for your client app to send the update request to a backend. The backend will verify that the update request is legit (aka the JWT is verified and the update does apply to the user requesting the change).
Another solution would be to theme the User Account Service's screens to add input fields for your custom attributes, as the documentation says that:
This screen can be extended to allow the user to manage additional attributes. See the Server Developer Guide for more details.
The second option seems the more secure. I hope that helps.
This seems to be possible with the Account Management API.
Unfortunately, I didn't find any official documentation about that. However, there's an example in Keycloak that demonstrates how to do it.
I need integrate Liferay (version 6.2) with another service which stores information about users. Communication with service occurs through SOAP.
Is it possible use users from service to authenticate to Liferay?
Liferay integrates with external systems through LDAP already. If you use that interface, you're set. If you need a proprietary API to access user information, you will have some work in front of you.
It might be worth examining the SSO implementation and intercept newly authenticated users on this level: With the user's identity, create or update a Liferay user account on the fly through LIferay's API. To me this looks like the most promising approach from an effort/maintenance point of view, with the little information I have about your situation.
Alternatively you could batch-update all (Liferay-) user accounts from time to time, based on updates in your external system.
Let me see if I understand what need:
1- Step 1: User prompted with A login page.
2- Step 2: The credentials entered by the user are checked against a web service (could be any service)
3- Step 3: The user is either logged in or an auth error displayed to the user.
If that's what you need, then create an autologin hook. The code that call the webs service shall live in the autologin hook.
May seem intimidating, but it is trivial: likely liferay comes with a bunch of them: (take one of them as a template)
auto.login.hooks=com.liferay.portal.security.auth.CASAutoLogin,com.liferay.portal.security.auth.FacebookAutoLogin,com.liferay.portal.security.auth.NtlmAutoLogin,com.liferay.portal.security.auth.OpenIdAutoLogin,com.liferay.portal.security.auth.OpenSSOAutoLogin,com.liferay.portal.security.auth.RememberMeAutoLogin,com.liferay.portal.security.auth.SiteMinderAutoLogin