I am building OneLogin SCIM Provisioner with SAML (Core Schema) app. I've created two controllers - Users and Groups. UsersController logic works perfectly - I can provision users and do all CRUD operations. But I am having issues with provisioning groups:
Based on the OneLogin articles (Get Groups and Provision Users into Groups) i get the initial GET hit that is trying to retrieve groups (when I refresh entitlements in OneLogin) but nothing comes accross on the OneLogin side. I've gone so far to return exact copy of the example response given in the article. Activity Event Log in OneLogin is showing that Refresh Entitlement operation has started and finished but the result of the operation is nowhere to be seen.
Has anybody experienced similar issue?
Every help and suggestion much appreciated.
Awesome that you're doing SCIM
In Onelogin groups and group memberships are expressed as "Entitlements" which is a fancy term for "things that can be set through rules in OneLogin"
So you need to go into your application and turn on provisioning for the Groups parameter.
Once you've refreshed entitlements (and your application has told OneLogin what groups you have) you should then be able to go into the "Rules" configuration in your OneLogin application and define rules to assign users to the various groups in your app.
Hope that helps.
Also if this is a commercial application (not something in-house) please contact scim-support#onelogin.com if you want something official and pre-configured in the OneLogin app catalog.
Related
I generate a auth link like:
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?access_type=offline&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar.events&prompt=consent&response_type=code&client_id=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fapplication%2Fsettings%2Fgcal&flowName=GeneralOAuthFlow
As you can see I call for the authorization as defined in the documentation here https://developers.google.com/calendar/api/guides/auth however, when I go to auth this is what I am presented with: and I thought this might be some new security thing from google but then I look at connecting to other sites and the account works just fine there.
This application is also fully verified for the consent screen.
While doing some comparison between my calls and other site's I notice that mine have /v2/ in the path while others do not. I have tried multiple individual google accounts with same result, but I always get a v2 redirect.
Anyone here know why this happens with v3 accounts and how I can solve it?
Unfortunately, this is the new default behaviour
It is realted to the new policy of More granular Google Account permissions with Google OAuth and APIs
It is being gradually introduced and is not related to either v2 or v3 accounts are being used but rather will eventually implemented for all accounts
Should the user not grant you all the scopes necessary for your Addon to run - you will need to handle it programmatically checking which scopes have been granted and requesting additional scopes if required
Best practive would be to make it very clear to your users PRIOR to the app installation that checking all checkboxes is crucial for the correct functionality of the app.
There is a very good stackoverflow post that explains the new change more in detail and includes many useful references.
Trying to create a SCIM application in Okta that would provision both users and groups.
Users seem to work as expected and I am able to push custom attributes for users to our app and also do the proper mappings.
However, I have some issues with Groups. I am using Push Group mechanism.
After I enabled the feature called Group Profiles for Universal Directory an Okta Group Profile was added to the Directory -> Profile Editors, to which I added some new attributes for groups (e.g. email, okta id).
If I create groups with these custom attributes and push them, the only information I get sent to our app is displayName and members.
This is the POST body:
{"schemas":["urn:ietf:params:scim:schemas:core:2.0:Group"],"displayName":"name of group","members":[]}
So no email or other custom attributes.
It is not clear to me how to differentiate our SCIM app attributes for users vs the ones for groups. In the attribute mappings I only see “From Okta user to My app”, and no “From Okta group to My app” and I can only choose user.attribute and not group.attribute.
Any help is very much appreciated!
I got an answer from support saying that provisioning through SCIM custom group attributes is not supported yet. The option might be available later this year, but there is no ETA.
I am creating a SCIM complient APP for OneLogin. I have implemented SCIM API. It works fine for /Users Request.
But I am not getting what will be the format for /Groups Request and when it will be sent. In which format they are sent and How to assign groups to people. And how to apply mapping for it..I Have read this article( https://developers.onelogin.com/scim/implement-scim-api ) on provisioning for this but it doesn't give me clear insights.
Also, Can one user be in multiple groups?
The first step would be to configure your application to first enable provisioning for the Groups attibute in your SCIM connector (this tells OneLogin that your application supports Groups)
Once that's done, you should 'Refresh Entitlements' and OneLogin will call the app's groups endpoint to retrieve what groups are available to assign users to.
From there you can add Rules to the application in OneLogin that assign users to groups and users can be assigned to as many groups as you want.
Details can be found here: https://developers.onelogin.com/scim/create-app
I received this message for the second time and i still dont understand why. Can someone help me?
Action required: Critical problem with your Google Cloud/API project
Youtube API (id: tonal-topic-123301)
Dear Developer, We have recently
detected that your Google Cloud/API project Youtube API (id:
tonal-topic-123301) is using a Google product name as the project name
shown to users on the OAuth consent screen, which violates the Google
API Services: User Data Policy. You can fix the problem by revising
the project name and other relevant content so that the OAuth consent
screen shown to users accurately reflects the identity of your
application. To revise the project name visible to users, please take
the following steps:
Please review the Google API Services: User Data Policy, specifically
the following section- "Do not make false or misleading statements
about any entities that have allegedly authorized or managed your
application. You must accurately represent the company, organization,
or other authority that manages your application. Making false
representations about client credentials to Google or Google users is
grounds for suspension."
Sign in to the Google Cloud Platform Console.
Select your project.
On the Home Page Dashboard, select Go to APIs overview under APIs.
In API manager, select Credentials on the left bar, then select OAuth
consent screen. Change the name in the field under Product name shown
to users and then click on Save. We will suspend your Cloud project in
3 days unless you correct the problem. Please submit an appeal if you
have any questions. Please note that you should be logged in as the
project owner to access the appeals page. For more help on submitting
an appeal or to learn more about the process check the Policy
Violation FAQ. Please take a moment to review the Google API Services:
User Data Policy, the Google API Terms of Service, the Google Cloud
Terms of Service and the applicable Terms of Service for the specific
Google API you are using so that you do not violate our terms and
policies in the future.
This is obviously a naming issue regarding something in the google product range.
You Should be able to re-name your project to solve this.
If not, try a Google forum or help pages.
The problem you are having is that Google does not allow you to use a Google product name as the name of your in your application. Users can become confused and assume your third party application was created by them.
How to fix it:
Go to Google Developer console find the credentials screen. Click on the Oauth consent screen tab at the top rename your application.
Note: If you don't do this google is going to shut down your application they are very picky about this.
We are using Sonhrqube 4.5 that is integrated into Google's oAuth sign-on. There are no issues with logging in (Authentication). Certain users have been provisioned with sonar-administrators role. But for some reason, the admin role keeps dropping for some users (leaves the user with sonar-users role). We have tried granting them admin access again, but it keeps happening. Also tried creating a brand new group and assigning that group to the user, but still same thing happens. Any thoughts? If you need any other information, let me know.
Just additional info, not sure if it matters - We are using the sonar-oauth-plugin from JCERTIFLab for integration with Google's signon/oauth. This plugin automatically creates users with default role - sonar-users.
Thanks in advance!
It turned out to be an issue with the Sonar plugin used for integration with google's Oauth. Every time a user is authenticated, permissions get overwritten. To overcome the problem temporarily, we predefined a list of users with admin access in the properties file.