I am provisioning a SCIM client from AzureAD. Create/update works fine. When a user is removed from AzureAD recycle bin (hard-delete), I also receive delete requests.
Now I have issues with soft-delete.
Microsoft documentation states:
If one of the above four events occurs and the target application does not support soft deletes, the provisioning service will send a DELETE request to permanently delete the user from the app.
How does AAD know if the target app supports soft deletes? In my current setup, I have not configured any active or IsSoftDeleted attribute mapping. So I would expect AAD to send me DELETE requests.
Well it turns out AAD "thinks" that I support this feature, because it tries to soft-delete my users (through update, i.e. PATCH requests). This is not what I want, I need DELETE all the time, as written in the documentation.
How can I achieve this?
(The SkipOutOfScopeDeletions flag does not work either. I was expecting it to convert soft-deletes to DELETE requests, but apparently it only skips soft-deletes completely. No conversion.)
Related
We have built a React web application that authenticates users with Microsoft via OAuth ( #azure/msal-browser package). Users are redirected to Microsoft auth page during signin, and then redirected back to our site once authentication has completed successfully. This is all working as expected.
However, we are in a position where we wish to add a custom PIN mechanism to protect some of our workflows. PINs will be encrypted/salted and stored in our own API, along with the existing mapping between Microsoft/Azure users and our own user state/records. In order for users to change/reset their PIN, we want to force them to reauthenticate with Microsoft before changing their PIN. I have not dealt with OAuth2 in a while, and am not entirely certain how this might be possible (since current auth workflow does not involve our server at all).
Ideally, users would navigate to the "Reset PIN" page and initiate the workflow. If possible, authentication would be handled through a pop-up (so as to not lose page state), which I think is possible as per documentation? If this is not possible, even a redirect to the same page with a specific query parameter (to indicate post-authentication) could work. The user would then be able to change/confirm their new PIN. At this point, a request would be sent to our API, including both the PIN and something from Microsoft that would allow our server to validate that the user did indeed just re-authenticate (proving they can change the PIN).
The primary sticking point is that our API must be able to verify that the user has just re-authenticated with Microsoft! One way to think about it would be that if a user gained temporary access to an unlocked authenticated workstation, they should not be able to perform restricted actions (as they do not know the PIN), nor be able to change the PIN (as they do not know the user's credentials). Yes, yes, I know physical access is effectively a compromise to any security, but this is a higher-level requirement...
I am guessing this workflow is possible, but am not certain how it might be possible. Would we use a different authentication workflow for this particular use case? Any pointers on a workflow we could investigate or use for this?
I can give you some info about how this should work. This type of flow can require a high level of extensibility in the authorization server though.
CLIENT REDIRECT
The client can send the OpenID Connect acr_values parameter, indicating the assurance levels it requires. In your case you would send two values.
CUSTOM AUTHENTICATION FACTOR
The user will perform standard authentication first, eg passwords. Then you would implement a custom second factor that uses the user identity and some custom logic to call your custom API.
ACCESS TOKENS
After authentication has completed, the authorization server will issue access tokens to the client. High privilege claims should only be included when strong authentication has been used. Some kind of scripting would be used here, that can read authentication result attributes.
API AUTHORIZATION
APIs should receive short lived access tokens. If it contains the high privilege claim, you know that your PIN requirements have been met.
CAN YOU SIMPLIFY?
It feels suspect to do your own PIN management. Can you outsource this, eg use a second factor of time based one time password (TOTP) instead? Mobile platforms such as the Google authenticator app provide tested solutions.
With IdentityServer4 I need to allow a single user session per time. If the user authenticates with device A and then with B, session and access token must be invalidated for A and, even better, client A could receive a notification that user has logged out in a second step.The main thing is making the server force invalidate session and token. There are similar questions, one of them redirects us to the following link:
https://github.com/IdentityServer/IdentityServer4/issues/736
where it is explained to use backchannel logout and in the login method of the identity server to obtain the previous IdentityServer sessionID that should have been persisted somewhere. Then I should send logout tokens to all clients.
Another solution is given here
How to Logout user from a particular session Identity Server 4, .Net Core?
telling us to use an ITicketStore implementation to be able to invalidate the session.
The configuration used is IdentityServer4 with authorizaton code flow with PKCE. Which approach is best for my case? Is there another approach where I could simply delete the access token in the id server database?
I think in your case probably a combination of both. In our real-world implementation we combine server-side storage of sessions via ITicketStore (stored in a custom database with sessions linked to user accounts and also storing the list of client IDs for each session) with the ability to trigger back-channel logout of any session at any time (i.e. not just via the default user-triggered mechanism).
In our case we do this to be able to invalidate sessions for other reasons (e.g. password or other security setting changes, a "log me out of everything" feature, impersonation rights being revoked etc) but this approach could form the foundation of a "single session per user" feature should you wish.
I am working on a integration with Salesforce using REST APIs and, as part of the project, I need to send updates to Salesforce and these updates are not user triggered, they are system triggered.
Because of that, what I expect to see on Salesforce Field History is not a user name but the name of our Connected App (the app that made the update).
What I see today is the user name because the way the integration was made initially using OAuth Authorization Code flow.
To change that part of the project, I followed the link (OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration): https://help.salesforce.com/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5
Making that, I was expeting to generate a token for a System, not for a User, but that's not what happened: when I used the token generate from the JWT Bearer Flow and ran the update, the Field History still shows the user name.
What could I do then?
Which are the options in Salesforce to achieve the behavior I'm expecting?
The most important, in my opinion, is to have a Token for our system, not for a user.
Thanks!
Everybody is an user in Salesforce. Even if you access unauthenticated pages (some contact us form? case or lead capture) - it gets tracked under special Guest User.
It sounds stupid but gives you unified interface to control permissions (Profiles/Permission sets). You want guests to access only FAQ articles and make cases? Sure thing, do it in profile, don't get paranoid about people trying to guess right URLs. You think an app was hacked? You can terminate the session just like any other "user". Want to allow login only in certain hours and from certain IP? Sure.
An app connecting with JWT will still need username (main difference being it's "just" certificate for signing the request instead of password).
Your best bet is to create dedicated "Mr System", "SystemX integration" account. It sounds like waste of license but in the long run saves you questions "why did you edit my account at 1 am" and you could even use it as backup account if you use SSO and it ever fails...
I have an application which needs access to mailboxes for an organization but likely only needs access to the mailboxes for the sales teams and not the mailboxes for the rest of the organization.
For Office 365 we create a service account and get it delegated access to each of the mailboxes it needs to read emails from.
It seems like the Gmail API supports a "userID" parameter.
How can I configure a service account user thru the Admin portal to have access to multiple mailboxes?
Unfortunately this is not possible because a service account acts on behalf of a user who runs the script and does not have the authorization to access other mailboxes.
As a workaround, in the Admin console, the administrator of the domain is able to set up the routing settings for Gmail in a such a way that a copy of all emails addressed to the Sales Team (Organization Unit “Sales Team”) will be delivered to an additional recipient - who will run the API.
When you set-up the routing settings as explained here and add a recipient to whom to deliver a copy of the messages, you can use the option “Advanced”, which allows you to decide to for example to forward attachments or Spam messages as you can see in the image below.
Furthermore, if you don’t want to forward all messages, you can set-up content compliance rules for the inbox of the additional recipient to whom a copy of the messages will be delivered.
I'm using the Google Apps Provisioning API to 1) create new users in our domain and 2), immediately after creation, move them into a sub OU which has the Mail service enabled. I would also like to use the Mail Settings API to 3) set a default SendAs for the new users at the same time. However, I don't seem to be able to set the SendAs until a small amount of time has passed. I get an InvalidValue(1801) ErrorCode. If I make the same call to the Mail Settings API a little later, it works fine. So, I'm guessing the problem is when the Mail Settings API call is made, the user hasn't been registered as being in the OU with the Mail service enabled yet.
Is there a way for me to set the SendAs immediately after the user creation and move? As a workaround, I can put a short delay in my code before the setting of the SendAs, but I'd prefer not to have to do this and I'm not sure what amount of delay would consistently be sufficient.
Thanks for any help you may be able to provide.
Sam LaSala
Any reasons you are still using the provisioning APi instead of the new Directory API? (https://developers.google.com/admin-sdk/directory/v1/guides/manage-users). Provisioning API has been deprecated, and it is subjected to the deprecation policy. It is better if you start using the new API instead of developing your code in the old one.
With the new API, you can actually combine step1 and step2 together where you can directly create the user in the OU that has mail enabled. That way it will eliminate the additional call, and the user will inherit the services that have been already turned on in the OU. Hope this will resolve the issue you have.
You can also check out the functionalities of the Directory API in the API explorer:
https://developers.google.com/apis-explorer/#search/directory/admin/directory_v1/