We use WSO2 API Manager 1.10.0 for our API Management. I've previously setup an API which is restricted via scopes-to-role-mapping. Now we have to handle multiple versions of this API (not all clients can migrate to the new versions at once), but it seems I can't reuse the same scopes (scope-keys and scope names) I've restricted a previous version with?
This seems strange? Does that mean I need to create unique scopes-to-role-mappings for each version of the API? That would mean that subscribers using the /default api would have to update their scope-names when requesting an access-token depending on which version of the API they're using?
What strategy should be used here? We usually create scopes with scope-key <API-Name>-<Restriction-Key>. Should I now then use <API-Name>-<Version>-<Restriction-Key>, and when users migrate, they need to update their scopes when requesting an access-token to the correct version?
I really hope it's possible for our users to simply keep using the same scopes when switching to a new version of our API somehow, or are they uniquely tied to a specific version of an API?
Found an answer to this.
Firstly, if creating a new version of an API by using the "create a new version" in the publisher, the scopes can be reused; but as soon as you try importing a new swagger-specification the scopes are removed and can't be reused under the "manage-phase".
I found out that the scopes are actually specified in the swagger-document stored in the repository under /_system/governance/apimgt/applicationdata/provider/<provider-name>/<api-name>/<api-version>/swagger.json. The swagger-document has a property called "x-wso2-security" which includes the scopes (which is read by the publisher during the "manage-phase"). It's possible to add scopes to the swagger-document (for e.g. copying the x-wso2-security property from a previous API-version), save the resource and open up the publisher, the scopes will then show up to be used under the "manage-phase".
I assume this is something the WSO2-development-team has missed when creating the publisher, but happily, it's possible to get around it by doing some manual work as described above.
Related
Currently, the Google Vault API does not provide a way to get a report of all users in a G-Suite tenant or domain who are on hold in one or more matters. This information is currently available only via the admin interface for Google Vault under Reports/User Holds. It would be great to be able to obtain this report via an API call in JSON format rather than only via the admin UI. Am I missing something or is this functionality already available?
Respectfully, please keep in mind that suggesting that I perform API operations to search all matters and iterate through the users on hold in each matter to obtain this information is not the answer I am looking for. There should be a quicker, more efficient way to get this information since such a report is already available via the UI. I am simply asking if there is a way to get this same information programmatically via the APIs/automation. Thank you in advance.
Unfortunately, Vault API does not have a method for that. The only way to retrieve this information is to list all matters and iterate through them, as you already mentioned.
File a feature request:
It's not uncommon for a feature to be present only in the UI. If you want to see this implemented on the API, I'd suggest you to report it on Issue Tracker's Vault component.
I looked through the issues of this component, and it looks like this hasn't been requested yet. There's currently a somewhat related feature request, but not exactly what you're looking for:
Audit reporting functionality
Update:
The original poster filed a feature request in Issue Tracker. I'm add this to the answer in order to give it more visibility.
To anyone who would like to see this feature implemented in the future, I'd suggest starring the issue (star on the top-left) in order to help prioritizing it:
Vault API: Need API method to return list of all users who have active holds as available in Vault UI
We've deployed WSO2 API Manager 2.0 and are very happy with it.
Although, we've been looking in the documentation if it is possible to add a field to the user profile but haven't found anything yet, is this at all possible? Also, if this is possible can we show the field somewhere on the frontend? Or better yet, is it possible to send it to a backend webservice?
Our problem is that we have a backend with users that have a token, but we didn't want to send that token to the API Manager, we want it to be added without worrying the user. Is this at all possible? We know about sequence mediation and this can probably be achieved with it, the only complication is where we store the user token, for each user.
Thanks in advance!
Best Regards
You can introduce new user attributes to user profiles. APIM uses WSO2 identity server features internally. So you can refer this doc.
If you enabled Supported by Default property, it will be shown in user profile.
You can use JWT to send user claims to backend. You can find docs here.
Last part is not much clear to me.
I created my own dialect using the manaement console Configure-->Claim Management. After doing this, I wanted to configure my Service Provider to be associated with these claims, so I edited my SP and went to the Claim Configuration section. The issue I am running into is the only Local Claim claims which show up are the default wso2 ones. So you only ever see ones starting with http://wso2.org/claims/.
With that said, I don't believe choosing Define Custom Claim Dialect is an appropriate alternative since I defined a dialect already. It would make zero sense to go an map that back to the default dialect, so I'm assuming this would not be the route.
Is there some configuration setting to list values from other defined dialects? Besides the one I created, there a quite a few that come OOB anyway. Is this a bug? I would assume my dialect along with all the other OOB ones would be Local Claim Dialects.
The Claims Management in the docs is just way to general to discern is there's some funny requirement. https://docs.wso2.com/display/IS500/Claim+Management
WSO2 Identity Server 5.0.0
I created a workaround, which works for my situation.
Once again, this is with IS 5.0.0. In my situation, no claims or dialects preconfigured fit my needs and I want my own special URIs defined ONLY.
So here's what I did:
In the Management Console, went to Configure-->Claim Management.
Edited the "http://wso2.org/claims" dialect.
Added each claim I wanted to this dialect. I was able to enter whatever URI I pleased, even though the dialect had a different URI (that's a good thing!) along with the property name I wanted it associated with. e.g., http://example.com/claims/claimname1
Then I went to configure the claims / attributes I wanted to be communicated to a particular Service Provider by editing its Claim Configuration...
Selected "Use Local Dialect".
For each claim I wanted to add, clicked "Add Claim URI" at "Request Claims", and selected a URI I created.
(OPTIONAL) I deleted all non-custom URIs in the "http://wso2.org/claims" dialect, because I found in my custom user store that getUserPropertyValues() was still getting passed every single claim attribute to resolve. It was trying to resolve more than 20 properties at every login. Some performance help! :)
I am working on wso2is4.6.
I am new to wso2is. Maybe this is a stupid question, but I am still blocked.
The first question: when there are multiple claim dialect in system, which claim dialect will be used? Which conditions will make system to choose this dialect instead of another dialect?
The second question: I install wso2is4.6, and install apacheds 2.0 with default (no customization). where can I find corresponding claim mapping?
I know I need to correct the claim mapping, but I don't know how can I find the correct mapping. Can somebody provide the workable claim-mgt.xml base on wso2is4.6 and apache2.0?
Adding more info to Dulanja's answer,
Q1. In WSO2 Identity server, internally it always uses a claim dialect together with a claim URI to identity a unique claim. Different components uses different dialects to get its claims. Fr an example when adding a new user using management console, relevant(user-manager) component would use WSO2 default claim dialect mentioned above. Similarly if you are doing SCIM related operations, relevant components will use SCIM dialect.
Q2. As mentioned in Q1, makes the unique claim and where we store that claim's value can be configured in two ways.
i. You can use claim-config.xml in /repository/conf/ folder and you can edit claim-to-ldapAttribute mapping by changing <AttributeID> which is given under every element.
ii. Or you can change claim mappings at runtime using the Claim Management page in management console. Please refer [1] for more info.
[1] http://docs.wso2.org/display/IS460/Claim+Management
Thanks,
Question 1:
The default claim dialect of WSO2 products is http://wso2.org/claims. This is the underlying dialect of the User Profile view - currently you cannot change this to use a different dialect.
Other dialects are used in different scenarios. As an example http://schema.openid.net/2007/05/claims is used when IS acts as an OpenID Provider. OpenID relying parties (clients) requests attributes using the claim uris specified under this dialect. Other examples are SAMLSSO and Passive-STS flows. In them you have the option to select the dialect that you want to use to send back the attributes to the client.
Question 2:
Are you facing a claim-mapping related problem with the new ApacheDS 2.0 LDAP? As far as I know, since WSO2 IS embedded LDAP is also based on ApacheDS, if you point (via user-mgt.xml) to such an LDAP the existing claim-mapping should work without any problem
I read that the Admin SDK works for Google Apps resellers, but I'm having one specific problem.
I want to use the following request to get the number of user licenses in use on one of my customer's domains.
https://www.googleapis.com/admin/reports/v1/usage/dates/%s?parameters=accounts:num_users
But there's no way that I can find to specify the customer's domain name that I want to get the usage report for. Tried a few different ways.
There must be a way that is hiding from me because this was possible with the old deprecated API.
Thanks.
Using the Reports API for this is not advisable because it can be delayed by 48+ hours. It's also not possible for reseller users to run reports for customers at this time. Rather, you should use the Google Apps Reseller API to list subscription counts that should be fully up to date.
Looks like this API here will do the trick:
https://developers.google.com/admin-sdk/admin-settings/#retrieving_the_current_number_of_users_in_a_domain