Does someone have a script that will go thru the OUs in Google Admin and return the settings for each group and subgroups?
I am looking for an easy way to compare the settings on multiple OUs.
Based from this documentation, to retrieve an organizational unit, use the following GET request and include the authorization described in Authorize requests. The orgUnitPath query string is the full path for this organizational unit. For the request and response properties, see the API Reference.
If you are an administrator retrieving an organizational unit, use my_customer.
GET https://www.googleapis.com/admin/directory/v1/customer/my_customer/orgunits/orgUnitPath
If you are a reseller retrieving an organizational unit for a resold customer, use the customerId. To get the customerId use the Retrieve a user operation.
GET https://www.googleapis.com/admin/directory/v1/customer/customerId/orgunits/orgUnitPath
Related
we're using Keycloack with activated LDAP-sync. The LDAP-provider uses a Custom User LDAP Filter which filters for department names.
Now there has been a organizational change in the department names, which resulted in no user was able to log into our application.
Is there a technical way, to maybe get a notification via mail, if there large changes in the number of synced users?
Regards
Lars
I have one account in docusign which has 3 users for it. We have a requirement of retrieving templates of users for that account. The Template:List API is retrieving all the templates of the account. There is also one path parameter named user_id but it is not retrieving the templates of particular user account instead it is retrieving all templates.
Is there any way through Rest API we will retrieve list of templates of user account?
If there Please provide the Rest API details or link.
From my own testing, it appears you're right. This could be a bug, I'm not sure and I'll follow up but this may take time.
Two possible workaround.
Make the API call in the context of the user that you wish you get templates. Basically, you'll need to obtain an accessToken for the API for that user. With JWT that is very simple, just use the userID when you ask for the token (but you do have to get consent).
Filter the list of templates you get. The list does include information about the owner of the template (again, userID) but you'll get all of them and have to do the work to find the ones you want.
(Update 5/26/2020: confirmed with engineering this is a bug. It is tracked under TT-3290).
(Update 6/23/2020: bug was resolved, will be deployed shortly)
Background
I'm building a application where all users belongs to a Organization. I only want the user to be able to Create/Read/Update/Delete records in the Organization they belong to.
I'm using sails, but I'm looking for Connect/Express-based, or a standalone answer as sails-permissions node module is unmaintained.
Question
How can one implement a authorization that allow CRUD only for the organization the user belongs to?
We are also not relying on sails-permissions. In our app, users can be members of multiple orgs.
We are using auth0 for all authentication activities, i.e. every request must include a jwt that is included in the request header. The jwt includes userId, orgId and role.
Sails policies decode the jwt and attach userId, orgId and role the the req object for all later checks.
Every model has the property orgId - we are using MongoDB.
Every controller, db operation, etc. adds this verified orgId to the query. Actually we have a small pipeline preparing the query: we add the orgId, in update cases we filter out unwanted property updates, etc.
This approach does not require additional db calls for separation of tenants.
Some models have specific access requirements per individual RECORD. Here we store allowedUser properties (one for read, one for update, etc.) on exactly this record and we extend the query once more so that only records are returned or updated or Xyz where the current user is included in the applicable allowedUsers property.
This approach also does not require additional db calls. This leverages MongoDB-specific query features, though.
We currently do not have ACL-like requirements which would be right between the 2 approaches I described above (re access control granularity).
You'll need to intercept each request using middlewares
combine them with a role system by checking if a certain token is present on request headers and in a acl map and finally, if the token is present in the acl map, see which permissions are related with this token.
I have specified the LDAP filter option as uid=${username} to get the username. I also need to get other attributes such as organization, telephone no, email etc.. I have only one LDAP store configured in my system. I know all the configuration steps to acheive it. I am struck with the LDAP filter to get those attributes. That's where I am getting error.
for eg, in order to get organization, I should give something like o=${SOMETHING}
How to provide the filter?
Please let me know.
Thanks,
Aswini J
I'm assuming you have already specified in the Assertion Mapping screen that you wish to "Retrieve Additional Attributes" and that you then added your existing LDAP Data Store.
The filter is simply used to locate a single user's record that you wish to return the associated attributes from. In the previous Admin screen (LDAP Directory Search) is where you specify the user attributes you wish to return. You simply specify your LDAP Base DN and then select the attributes from the drop-down list. You can find more information in the Admin Guide -
http://documentation.pingidentity.com/display/PF73/Configuring+an+LDAP+Directory+Search#ConfiguringanLDAPDirectorySearch-2232188
After choosing the attributes, you then get to setup your LDAP Filter where something as simple as "uid=${username}" will usually suffice. It really depends on what user identifier is coming in from your IDP Adapter and how specify that lookup needs to be. If you're using the HTMLForm Adapter, then chances are your users are entering their LDAP userID values.
I have an API that provides an Account resource based on the authentication (login) that is supplied. As a user can only have one account, and can only see it's own account and not those of others, this API will basically be a single resource API in all cases.
So to keep things simple, I have this resource under the url accounts/ and when you access accounts/?username=dude&password=veryhard you'll get your account data (if you dohn't supply authentication you'll get a 403).
Now I wonder if this is RESTful. Also, you should be able to update your account info, and I wonder if PUT would be appropriate. In my knowledge, PUT should be done on a unique URI for the resource. Well, is this a unique URI for the resource? Generally a URI for an account would look like accounts/3515/ where 3515 is the account id. However, users don't know their account id. Also, there should be more ways to log in, instead of a username + password you should also be able to use a token (like accounts/?token=d3r90jfhda139hg). So then we got 2 URL's that point to the same resource, which also isn't really beautiful for a RESTful URI, is it?
So, what would be the most RESTful solution? Or should I not do this RESTful?
REST purists will consider that use of /accounts/ to obtain a single account is bad practice as it should specify a collection. Instead consider a key which cannot be mistaken for an ID, for example if your IDs are UUIDs then use a token such as 'me' so your URL is /accounts/me. This has the advantage that if later on you wish to obtain different account information, say for example you need to list users or you have an administration system using the same API, then you can expand it easily.
Putting username and password in the URL is also not pure REST. The query parameters should be directly related to the resource you are obtaining; commonly filtering and limiting the resources returned. Instead you should seriously consider using something like HTTP Basic authentication over an encrypted (HTTPS) connection so that you separate out your authentication/authorisation and resource systems. If you prefer to use a token system then take a look at oauth or hawk.
Finally, yes if you use PUT you should supply a full resource identifier. Given that it is very common for systems to read data before updating it the lack of ID won't be a problem as that will come back as part of the prior GET.
Yes accounts/?username=dude&password=veryhard is a correct REST URL.
PUT is used with an id if it used to update a resource, if you use it to create you must supply an ID. otherwise you use post to create a resource without id