We've populated a test google instance with user data such as externalIds that are unique to our institution - see https://developers.google.com/admin-sdk/directory/v1/reference/users#resource
We have wso2 server 5.4 and are exploring using Google as our IdP. However, we are a bit new to SAML/Oauth/OpenId, etc, and are just beginning to learn about them in depth.
We've successfully connected Google to wso2 as an Identity Provider using Federated Authenticators.
However, when we use that IdP for an SP (saml or oauth), it only returns a default set of information about the user. How can we return more profile information that is stored in Google?
I've been reading about scopes and claims and, etc.. but I'm not connecting the dots so far.
If I populate "customerId" in the Google Directory using their API for all our users, how can I get wso2 to return that information to the SP?
You can use wso2 claim handing to achieve it. When configuring IDP, in the "Basic Claim Configuration" you can enable "Define Custom Claim Dialect". Then add claim map "customerId" to a wso2 local claim(http://wso2.org/claims/userid). In the SP configurations' "Claim Configuration", you have to add that particular claim(http://wso2.org/claims/userid) to the requested claim.
Related
Our use case is to connect Azure Datafactory (ADF) to AWS S3, but use the Managed Identity (MSI) of ADF for authentication and authorization.
TL;DR version
The problem we run into is that we require the access_token for the MSI in ADF, so we can exchange that for temporary credentials in AWS IAM service. We need this access_token in text, such that we can provide it in the right way to the IAM service.
Situation (longer version)
High over, the solution should work like this:
ADF will get an access token for a specific resource using MSI
Using the access token, ADF will then get temporary credentials with AWS
Using the temporary credentials, ADF will get data from S3.
In order to do this, we needed a couple of things (heavily inspired by this blog):
Azure side:
We created an App Registration, and set an Application ID URI (which will be the 'scope' claim in the AzureAD access_token request).
We created a custom role in that App Registration.
In the Enterprise Application object of this App Registration (at this point, I feel like I should appologize for Microsofts terminology..), we have ensured that User Assignment is required.
We have assigned the custom role to our ADF MSI.
AWS side:
Added our AzureAD as an Identity Provider
Set the audience to the same value as Application ID URI.
Added a new role with a trusted entity of type Web Entity, and added proper S3 permissions to it.
Then to test this all out, we created an Azure Function (http triggered) which returns the request headers as body. We then created a Web Activity in ADF to this Azure Function endpoint, and set the authentication to "System Assigned Managed Identity", with a resource the same as the aforementioned Application ID URI. The result is that we get the Authorization header value, which we then manually put into a request to the AWS IAM service to exchange for the temporary credentials. The request to the AWS IAM service has the format of https://sts.amazonaws.com/?Action=AssumeRoleWithWebIdentity&RoleSessionName=app1&RoleArn=<arn>&WebIdentityToken=<access token>. This provides us with credentials, which can be used in a Linked Service in ADF (we tested this).
Problem statement
We now use Azure Function, in order to have ADF automatically get an access_token for the requested (AWS) resource (Application ID URI), and add that access_token to the request to the Function, which solely returns it to us. We want to do this without an additional component. I can think of two ways:
(option 1) - A web activity to some Microsoft endpoint that returns the access_token immediately.
(option 2) - Have AWS take an Authorization header rather than a WebIdentityToken query parameter.
I spent some time on option 2, but that seems like a no go; the access_token really needs to be part of the URL parameters when trying to exchange them for temporary AWS credentials.
Option 1 however, I had an idea; there is the IMDS on virtual machines in Azure. This can be used to get access_tokens when you are on a VM rather than a PaaS service. I tried making a call to http://169.254.169.254/metadata/identity/oauth2/token?api-version=2021-12-13&resource=<Application ID URI> using Web Activity (both with a AutoResolveIR and a SelfHosted IR!), but I got the error [ClientSideException] Value does not fall within the expected range. I did set the header Metadata to value true as described in the docs.
Is there another way? Apologies if this is an abundance of information, but it does provide you with all the required details of what has been tried and how the setup should (and can) work.
It sounds like you're using Azure AD as an identity provider in AWS. If possible, you can create a AWS user with a permanent access key/secret key. The AWS user can have access to your S3 buckets, and you won't need to deal with STS in ADF.
Another idea is to use Azure KeyVault. When you create your S3 linked service in ADF, you can parameterize the access key and secret key. Your AWS access key and secret key will be stored in Azure KeyVault. Then you can have a Azure function that updates the KeyVault on a schedule or at the start of your ADF pipeline.
To obtain the access token, you could try using the Azure REST API. To obtain the access token for the specified resource using the MSI, you might use a Web Activity in ADF to make a REST API request to the Azure REST API endpoint.
Set an Application ID URI and create an Azure AD app registration.
The app registration should include a custom role.
Give the ADF MSI the custom role.
REST API calls to the Azure REST API endpoint that return the access
token for the specified resource using the MSI can be made using a
Web Activity in ADF.
The URL for the REST API is:
https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
{tenantId} should be changed to your Azure AD tenancy ID.
In the REST API call, enter the following values:
grant_type: client_credentials
client_id: <application_id>
client_secret: <application_secret>
scope:
We are currently working on an Angular node application which uses WSO2 Api Manager and Identity Server . The current mode of login is done through emails which gets saved as WSO2 Carbon users . We need to allow users to login using their google or facebook accounts using OAuth2. I have implemented the code for fetching access token,refresh token on login through google on click of a button from my app . But How can i link it to save this user as a user in our application's identity server . I found the below link which helps in the process: https://docs.wso2.com/display/IS570/Logging+in+to+an+Application+Using+Google#50629d9a6ddf4769ae2d8953c5a25645 .
Can anyone suggest me whether this one would help ?
I would like to know how the google account user details will be saved as a user in our identity manager ?
Is it possible ? If possible, what all data will i get from google ?
I assume that you have already done the configurations for the communication between your application and the WSO2 Identity Server according to the description in the question.
From the description, I'm not certain that you have done the configurations to federate the login to Google. Follow the below steps if you already haven't done so.
Generate OAuth client ID from the google developer console.
Configure a federated authenticator in WSO2 IS with google authenticator using the generated client id and secret values.
Add newly created IDP as an option to the first step of your application.
More information can be found in here. From Google, you can get email and default profile attributes of the user. Reference.
Follow the same steps for Facebook login as well. More information available here.
Now the federated login is configured. Now you need to enable JIT provisioning for the configured Identity Providers above to save the user in the Identity Server when the user is logged in with those social login options. More information available in here. You have a few modes to create the user in the Identity Server.
Hello friendly StackOverflowers,
we are using WSO2 Identity Server 5.6.0 and are trying to use OpenID Connect to secure applications.
I followed https://docs.wso2.com/display/IS560/Configuring+Claims+for+a+Service+Provider and created custom external oidc claims mapping to local claims. I also added the oidc claims to the oidc file in the registry.
It appears though, that the documentation is not fully up to date as there is an additional dropdown in 5.6.0 with the Service Provider Claim Dialect.
When we try to login, the login itself works, but the claims are not attached to the id token correctly. Even though the claim manager was able to retreive the claims, as I see in the logfile.
I tried a couple different variations (Custom Claim Dialects, Local Claim Dialect and also choosing just the Service Provider Claim Dialect), but nothing worked.
Interestingly:
If I choose a claim as the subject, and the consent is given by the user, the claim is attached to the id token - even if I remove it from the subject again.
I managed to get all the claims working, by choosing them as the subject, one by one, and giving consent during the login.
This however only works for this particular user.
Anyone got a pointer to how I have to configure the OpenID claims in 5.6.0? In 5.3.0 they did work with the same configuration.
Regards,
Mat
We are setting up an Identity Server 4 instance and one of the GrantTypes we wish to use is the Client Credentials Grant Type.
Is there a way we can link Client Credentials up to a use an AspNetIdentity user so we can get the claims and users details back for the client credentials provided?
Thanks in Advance
The Client Credentials grant type does not represent a user, it represents an application, so you would not use AspNetIdentity with the client credentials grant type.
If you want to include user specific claims you need to look at one of the grant types which involves user authentication. Examples are available in the quickstarts here. I would advise looking first at the Resource Owner flow and then the OpenID Connect based flows.
The quickstarts also include an example of integration with ASP.Net Identity, that can be seen here
I looked at the OAuth2 support in Google -
https://developers.google.com/identity/protocols/OAuth2
I don't see a notion of tenancy. How do I register a tenant specific client?
Any suggestions?
When you say tenant, are you referring to a Google Apps for Work domain? And when you say "tenant-specific client", do you mean that you'd like to restrict access to users in a particular domain?
In those cases, what you want is the hd param which is documented as part of the OpenID Connect protocol (OpenID Connect is an identity layer on OAuth).
Specify the hd param on your auth request, and importantly verify that the ID Token returned has a matching hd claim (to protect against client manipulation).