Chatter Moderator User Security Token - salesforce

This is the my problem in very short way;
Is it possible to get security token for Chatter Moderator User on salesforce ?

A Chatter Moderator is just a normal user with some special permissions, so yes, that user can log in and retrieve his security token by going to Setup (or by clicking on his own name in the new Setup UI) and going to Personal Information -> Reset My Security Token.

Related

IdentityServer4: How to set a role for Google user?

I have 3 applications:
An IdentityServer4 API which provides Google authentication and also provides an access token to authorize the resource API.
A simple Resource API which provides some data from DB.
A simple Client in React which have 4 buttons:
Login, for Google auth
Logout
Get data - a simple request with the access token to the Resource API and gets the data from Db
Get user data - returns user profile and token (for debug purpose)
I didn't put any sample code because my problem is not code related, it's knowledge that I'm missing and I ask for guidance.
The workflow is working just fine: the user press the Login button, it is redirected to IdentityServer4 API for Google Auth. From there it is redirected to a Callback Page from the Client and from there to the Index page. I receive the user data and the token, I can request data from the Resource API and it's working.
My problem is: How do I give a Role to the Google Users ?
I don't have users saved in DB. I want three types of Users: SuperAdmin, Admin, Viewer and each of these roles have limited Endpoints which can access.
For limiting their access I saw that I can use Claims-based authorization or Role-based authorization.
So, my question is how ca I give a Google User who wants to login in my app, a specific Claim/Role ? What is the workflow ? I must save it first in DB ? Or there exists a service from Google where I can add an email address and select a Role for that address ?
Thank you very much !
After you get the response from Google in your callback you can handle the user and do what ever you want to do with it. Below are the some typical tasks that you can do in callback that I took from documentation page of identityserver4 link:
Handling the callback and signing in the user
On the callback page your typical tasks are:
inspect the identity returned by the external provider.
make a decision how you want to deal with that user. This might be
different based on the fact if this is a new user or a returning
user.
new users might need additional steps and UI before they are allowed
in.
probably create a new internal user account that is linked to the
external provider.
store the external claims that you want to keep.
delete the temporary cookie
sign-in the user
What I would do is creating an new internal user account that is linked to the external provider and add a role to that user.
If you don't want to save users in db, you can add an extra claim to user in callback method and use that claim in token. and i think this link will help with that.

How to update id_token after user has updated his profile

I have set up identityserver 4 with an asp.net mvc web site using it for authentication (implicit grant type). I need have to have the claims on token updated when the user modifies the profile of the account but it is not.
Everything is working great in the happy path, client authenticates, then redirects back to website, claims comes through - all good.
My web site has a link that sends the user back to the IdentityServer in order to update the profile (name, email, phone, etc) but once this is completed and the user is sent back to the web site the claims are not being updated with the new information.
I can see that my user claims factory is being called from the profile service and that the new profile information is being set in the claims, however my website doesn't seem to pick up the new information. What might I be missing? Is this even the correct approach?
After the user logged in claim information is saved in a cookie. It will not be updated until the user logs out and logs in again. You may need to sign out user forcefully so that he must log in again after a profile update.
But if the user does frequent profile updates you may need to rethink having profile data in id-token and then in claims. There is a user info endpoint in identity server that you can query to retrieve profile data when needed.
http://docs.identityserver.io/en/latest/endpoints/userinfo.html

Connecting to exchange online using Microsoft Graph APIs through a Demon application

I'm trying to connect to exchange online and do certain operations with the emails using Microsoft Graph API 1.0 and this is all done in a demon program. I'm using Client Credential workflow for authentication, below is the small piece of code
AuthenticationContext authenticationContext = new AuthenticationContext(string.Format(CultureInfo.InvariantCulture, azureEndPoint, tenant));
ClientCredential clientCredential = new ClientCredential(clientId, clientSecret);
AuthenticationResult authenticationResult = await authenticationContext.AcquireTokenAsync(resource, clientCredential);
But for this code to return the authentication token I have to get Application Permissions to the azure app id against microsoft graph api. The caveat here is if the permission is granted, the application id will have access to read emails of all users in the organisation and due to this reason tenant admin has strictly refused to grant the permission.
I tried my luck with consent framework but that requires user intervention to enter his/her id and password which is not possible in case of a demon program. I read few blogs like below but they all end up entering the user id password to get to the redirect url which defeats the whole demon thing https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/
Is there any way I can give read/write access to azure application id for specific email ids in the tenant? Or alternatively any smart way to somehow get to the mailbox without user intervention?
Thanks in advance,
Vivek
You can only use app permissions with client credential grant flow.
To access only specific users' emails, you'd have to do a different approach.
This does require each user to consent individually.
Have the users login to your app, require consent for access to their email.
Upon returning to your app, acquire a refresh token and store it securely.
A refresh token is user-specific.
Then in your daemon service you acquire an access token for each user using their refresh token.
If the acquire fails because the refresh token has been invalidated,
the user will need to be notified to login again.
This is now resolved as microsoft has introduced a new concept of limiting application permissions to specific mailboxes or set of mailboxes using Group Policies. Check here https://learn.microsoft.com/en-us/auth-limit-mailbox-access

salesforce how to login with javascript without security token

I have set up the custom login page for my application using the following resource.
http://brianpeddle.com/2011/06/06/building-a-custom-salesforce-login/
However this approach requires security token for each user if the user is in untrusted network and the security token changes when user reset password.
How can I set up so that I allow multiple user login from this page? Currently only I can think of is have an extra input box so that user past the security token along with username and password. I wonder if salesforce allow javascript to grab security token dynamically for each user
OAuth2 is a security implementation that allows users to access their Salesforce data without having to enter their user/password in an untrusted application or do nasty token management themselves.
Salesforce has a guide on how to implement OAuth2 for web sites. It can be difficult to set up if you don't have any experience with OAuth2, but there are plenty of guide available.
I would also recommend using something like Firefox's RESTClient addon (or something like it) to test the use of OAuth2 to get a feel for authenticating against Salesforce .
Are you sure you have white listed the IP?
I strongly belive if you get the IP of server where your custom login page is hosted and put that in list of white listed IP's then User will not required to enter their security token.
to find the ip of your server(where your page is hosted)
- try to login with your custom login page
- login into SFDC and go to setup -> user profile-> login history
there you will see last login from IP
Copy above IP and
Again go into Setup -> Security control -> Remote site setting
and add above copied IP.
this way SF will not required security token when user is login from that IP.
http://ap1.salesforce.com/help/doc/en/configuring_remoteproxy.htm
Use this code for just login:
https://login.salesforce.com?un="+username+"&pw="+password+"&startURL=/apex/somepage

Salesforce: impersonation using the API

I'm a Salesforce system administrator and I would like to use the Web Services API on behalf of (ie: impersonate) a Salesforce user that is part of my company.
More precisely, I'm looking for a feature similar to what Google Docs already provides: https://developers.google.com/google-apps/documents-list/#using_google_apps_administrative_access_to_impersonate_other_domain_users
Can this be done ?
Thanks !
The only way to do this is to authenticate with the API using the other user's credentials. This is a security feature that cannot be avoided.
This is should be possible if you have login access for that user and a tool to inspect a browser cookies.
When you're logged in as the test user open a cookie browser and grab the value in the "sid" cookie. This is a session id for that user and can be set in the headers of an api request instead of doing a login call.
I've haven't tried this. It's possible that this session id may only be valid for the browser and not the API. In that case you should probably just create a test user with the same profile and your email. If all else fails just ask the user to temporarily change their password and share it with you.

Resources