I have an wso2is with AD as a data store
I'm trying to provide SP with claim that contents less data (cap is at 4k) but my "role" claim is too big for general users. Is there any way to create additional "role" like claim that could be filtered with prefix for example? Like only ad groups with name asd-* are included in this claim.
Related
In WSO2 IS admin console, we are trying to set the user claims for a service provider under 'Claim Configuration'.
We selected the Claim mapping Dialect as 'Define Custom Claim Dialect' and added Local claims as :
http://wso2.org/claims/givenname
http://wso2.org/claims/lastname
http://wso2.org/claims/emailaddress
But when we perform a curl with /oauth2/userinfo, it just gives us last name and email. But first name is not being returned.
Returned User Info:
{"sub":"abc#carbon.super","family_name":"abcFN","email":"abc#abc.com"}
Any pointers for the issue will be helpful.
There is actually an error in the mapping of the given name attribute between the oidc claim and the wso2 claim :
In the management console, go to Home > Identity > Claims > List > claim.view
Click on http://wso2.org/oidc/claim in the Available Claims Dialect list
Change the mapping for given_name to Mapped Local Claim : http://wso2.org/claims/givenname
In order to get the first name through user info endpoint,you should have an OIDC claim mapping with http://wso2.org/claims/givenname.
Could you please check whether your given_name claim under oidc dialect has a mapping with http://wso2.org/claims/givenname.
In my AWS Cognito App Client settings, it offers me two settings for email: one with a capital E (Email), and one with a lowercase e (email). See screenshot below.
What is the difference between them?
Assuming you referring to the "Email" listed under Scopes vs. the "email" listed under Attributes:
Uppercase Email is a Scope and lowercase email is an attribute.
OpenID defines an attribute as "The base of the information model used to describe the Identity Data, for the purpose of exchanging it."
A Scope is used to group Attributes. A Scope defines what resources can be accessed via an OAuth2.0 guarded endpoint.
See more info here
In this screenshot, you are defining Read/Write ability over those specific attributes. Attributes you cannot mark as writeable are Required fields.
EDIT: An App Client provides an avenue for you to call unauthenticated APIs for registration, password resets, sign in, etc.
If you uncheck a scope under Readable or Writeable you will notice all attributes associated with that scope also uncheck, or you turn off individual attributes.
By unchecking you are disabling the ability for those fields to be received (read) or modified (write) through the API.
Why would you want to do this?: let's say you have a mobile app, web app, and a fat client/server side application sharing the same user pool. you would not necessarily want all three to have the same permissions when talking to the unauthenticated APIs. An App Client allows you to create an individual connection with tailored permissions per App Client ID.
See here for more info.
I have added a local custom claim namely http://wso2.org/claims/fg_imprenditore to http://wso2.org/claims dialect and mapped it on a custom primary user store attribute (JDBC user store).
The custom claim appears in the user profile and I can set/update the value correctly.
I have defined a new service provider and added the custom claim in Claim Configuration -> Use Local Claim Dialect.
In addition I have edited /_system/config/oidc and modified the openid property to include the new claim as follows: sub,...,street,http://wso2.org/claims/fg_imprenditore
Now the issues.
I ask a JWT Token from a javascript client with the following request:
http://**********/?response_type=id_token&client_id=" + "f8SatEWpyi1qvPLVspsDfTbefm0a" + "&scope=openid&redirect_uri=http://localhost:3000/oauth_callback.html&nonce=" + nonce
After login the WSO2is server prompts the following message (even if the attribute is already present in the profile): You are trying to login to **** application, but it needs following information filled in the user profile. You can fill those below and proceed with the authentication. But it is advised to fill these information in your Identity Provider profile in order to avoid this step every time you login.
If I fill the field (correctly) labeled "http://wso2.org/claims/fg_imprenditore" I can proceed. In any case the claim is not returned in the JWT Token.
In addition if I go in the user profile the attribute is set correctly (with the new value!) but if I try to authenticate again I need to fill the attribute again..
Many thanks for the support.
If you don't mark the claim as mandatory on your Service Provider it shouldn't request it when you try to log in. Also, in order for the jwt to contain your custom claim you need to map the custom claim to a new custom claim under the oauth dialect, and then map the new oauth claim under the oidc scope you use. It took me a while to get it too as there isn't sufficient documentation describing these steps. Hope this solves your issue.
This happens because "http://wso2.org/claims/fg_imprenditore" claim is not mapped to any oidc claims in WSO2 IS. Do the following in get rid of the issue.
Go to List under Claims in IS Management Console Main tab.
Click on http://wso2.org/oidc/claim
Add new claim with the name fg_imprenditore in oidc claim dialect. You will see a drop down to select "Mapped Local Claim". Map it to http://wso2.org/claims/fg_imprenditore. (Check "Add External Claim" section in this)
Save new oidc claim and try again.
I have created XACML plocies with Wso2 GUI.
I used Basic Policy Editor for the same. I gave following parameters
For policy (in first tab I only gave Resource Name, kept other fields blank):
Resource Names : https://www.xyz.com/blabla/
(in second tab)
Rule Effect: Permit
USer's : Role is equals Architect
Action Name : is equals Read
So the policy is generated with this condition:
Architect
here the attribute id is : AttributeId="http://wso2.org/claims/role"
Now while I am trying to test this poicy with Tryit tool, with passing parameter in GUI ,
the automatic request is being generated from WSO2 which has following attribute id for the Role:
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
And because, the policy attribute id doesn't mached with my test request attribute id is continuously giving Intermediate reply.
I read some blogs and understood that attributeId must be matched while sending the request.
I change the request manually and then its working fine.
The question here is , why WSO2 Identity server is creating request with different attributeID, while we already created the policy from the Same Wso2 identity server?
I think both should be matched while you are using the same editor to create it and test it with same parameters.
Or I m missing something here??
I think you mean you are getting Indeterminate instead of Intermediate. There is no such response w/ Intermediate in XACML.
Secondly the attribute ID "urn:oasis:names:tc:xacml:1.0:subject:subject-id" represents the user identity e.g. Alice, Bob, Carol. What your policy needs is the role. You can have a request that only contains the user identity in which case the PDP will have to resolve the role from an underlying source. That underlying source is called a PIP.
You can also directly pass in the role from the request but in that case you do have to make sure the attribute identifier matches the one used in your policy namely http://wso2.org/claims/role.
If you have issues with the UI, give ALFA a go. It gives you more visibility over which attributes are used.
Yes. http://wso2.org/claims/role is refer to user's roles in Identity Server. Then PDP know call the PIP with this claim uri. PIP would extract the roles of the user. Mostly in your case, Indeterminate can be due to that user's roles can be retrieved. Please refer this for get more understand about RBAC/ABAC with Identity Server
BCS Security trimming with an ADFS login to SharePoint 2013 is not working for me with a custom connector. By not working I mean that when logged in via windows authentication, a user that has access to these BCS records can see them in search (this is correct). The same user logged in with ADFS cannot see these same records in search (this is not correct).
The setup I have is SharePoint 2013 on Windows 2012 R2 with ADFS. A SQL server database is being crawled via BCS with a custom .NET connector. The connector provides security trimming at crawl time by adding ACLs. The ACLs are created based on an AD Security Group that has a number of AD users as members (the logged in user is one of these members). The AD Security group is included as part of the claim and shows up as follows:
<saml:Attribute AttributeName="Group"AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>BCSSecurityGroup1</saml:AttributeValue>
</saml:Attribute>
BCSSecurityGroup1 is the AD Security Group that contains the users.
The odd thing is that even if I give everyone access to these records within the ACL (i.e. using WellKnownSidType.WorldSid), the ADFS logins still do not get these items returned in search. Even stranger is that if I go to the url for the BCS profile page for the record(s) in question, the ADFS user does have access.
Here is the question. What do I need to do to have search results reflect the ACL added security at crawl time?
As it turns out, this is actually pretty straightforward to get working. First, the AD Security Group was changed to individual AD users for troubleshooting purposes (domain\username). Looking at how the ACL is built in the connector, the domain account is used to get the SID, and the SID is then used to build the ACL. Ah ha! so the missing link is that with the AD FS claim, the SID is not being mapped. This was determined by using the Fiddler plugin to show claims under the inspector tab - http://identitymodel.codeplex.com/releases/view/52187.
Adding the SID claim in AD FS is done as a claim rule. Add a claim rule from the "Pass Through or Filter an Incoming Claim" template. Give it a name, select "Primary SID" for the Incoming claim type, and ensure that "Pass through all claim values" is selected. Restart the AD FS service for peace of mind. Also, this assumes that the Trusted Identity Token Issuer in SharePoint was created with a SID claims mapping.
In my case, I had to run another crawl on the BCS content source due to changing back to user names from AD security groups. Although I have not yet tested this, AD security groups should work the same way, but by passing through the Group SID. Hope this helps someone in the future. Cheers!