I called this revisited since there are existing questions under the same title. These indicate that the problem described would be solved starting from IS V5.3.
However I am using IS V5.7.0 and still have the problem that my userinfo call only returns something like {"sub":"Peter"} or an email address if so configured as " Subject Claim URI" under my SP.
Whatever I do with "local claim" settings seems to have no effect in this scenario.
In short it is a complete mystery to me on how to acquire more than a single attribute value from an open id connect call to ws02 IS.
All help appreciated
Thanks Peter
There was an issue already reported for versions below IS 5.3.0 and it was fixed with IS5.3.0 onwards. Please check the Jira here. I was able to invoke the userinfo endpoint in IS5.7.0 and able to get the claims successfully.
Sample request:
curl --location --request GET 'https://localhost:9443/oauth2/userinfo?scope=openid' \
--header 'Authorization: Bearer 7ca4671f-ab55-33b2-978e-b0795dacc1ef'
So please verify the following things.
Response:
{
"country": "SL",
"sub": "piraveena",
"email": "piraveena#wso2.com"
}
So please verify the following things.
Check whether you have configured those claims under claim configuration in the service provider.
Only the claims listed under openid scope will be returned from userinfo endpoint. Also please make sure that those claims are added into openid scope. In the management console, Navigate to Manage > OIDC Scopes > List > Openid and check whether the requested claim from the SP is listed under the openid scope. Please check this documentation for configuring adding claims in openid scope
Also verify whether the authenticated user has those relevant attributes in his user profile
Also please check whether you were able to get the claims in id_token. If you have not configured the above steps properly, then you won't be able to get those claims in id_token as well.
Related
I'm trying to setup a VPN connection using a federated login with Google IdP following these instructions.
Previously, I had configured a saml-provider with Google and it worked fine to authenticate users to the AWS console through Google using ARN roles
WHen I setup the VPN connection, it successfully opens the browser and asks me to select my google account, but after selecting the account I'm getting an error message from Google
According to this help section
Verify that the value in the saml:Issuer tag in the SAMLRequest matches the Entity ID value configured in the SAML Service Provider Details section in the Admin console. This value is case-sensitive.
So this is a problem coming from AWS and not from me ? Is Google IdP compatible at all with VPN authentication ? (I found this doc that mentions compatibility with okta)
Edit
Thanks to some of the answers below, I managed to make it work with Google IdP. Here is a screenshot of relevant SAML Google app screens (note that for groups I ended up adding the employees department, but I guess anything else would have worked)
To be able to save an ACS URL starting with http:// in the G Suite interface, use the trick given by teknowlogist: open the inspector > network tab, perform the request to save an URL with https, then right-click copy it as cURL, replace https by http, paste in regular console, and you're good.
I found a workaround to not being able to input http://127.0.0.1:35001 as the ACS URL on the GSuite SAML app page. The Google admin console only does client-side validation for the https requirement, so you can use the Chrome console to monitor the network call made when modifying the ACS URL.
Then, you can copy this as a curl command and change https to http
#Ted Schroeder —
Previous approach (or, plain Google doesn't work)
I just used a reverse proxy:
mitmproxy \
--listen-port 35000 \
--mode 'reverse:http://127.0.0.1:35001' \
--set keep_host_header=true
If you change Google SAML's ACS URL to be https://127.0.0.1:35000 and click "Test SAML Login", Google will take you to https://127.0.0.1:35000, whose traffic will be redirected to http://127.0.0.1:35001. In the browser I get:
Authentication details received, processing details. You may close this window at any time.
However, using the SAML-tracer extension, I found that there was a URL mismatch (https://127.0.0.1:35000 vs. http://127.0.0.1:35001). Seems like the AWS VPN Client is broadcasting its expected URL as being http://127.0.0.1:35001. So this doesn't seem viable.
Current approach (or, Auth0+Google works)
I tried using Auth0 instead, and got it to work! There's a few hoops — for instance, create a new Auth0 application, go to Addons and enable SAML2 Web App, set Application Callback URL to http://127.0.0.1:35001, and then in Settings use the following:
{
"audience": "urn:amazon:webservices:clientvpn",
"mappings": {
"user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"email": "NameID",
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"given_name": "FirstName",
"family_name": "LastName",
"upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"groups": "memberOf"
},
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect",
"signResponse": true
}
Then users, if they download the VPN config from AWS and use the AWS VPN Client app, will be taken to an Auth0 login screen where they can login via Google. Voila! (And then for security, you need to add Auth0 Rules to grant only certain users/groups authorization.)
I don't have a full answer yet, but I have the beginnings of one and I actually got past the 403 error above. The key to all this can be found in the AWS Client VPN information here: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html
Look for the section entitled "Service provider information for creating an app".
The key is that these are the ACS URL and the Entity ID that need to be used. Unfortunately, G Suite won't let you set the ACS URL to a non-https URL and apparently the AWS Client VPN app won't provide a secure URL for the ACS URL (where the SAML Authenticate response goes).
So, if you set the Entity ID to "urn:amazon:webservices:clientvpn" and have the G Suite SAML app in place according to the instructions, you'll get past the 403. However, since the ACS URL can't be specified you get whatever error message you're likely to get from the ACS URL that the authentication response goes to.
Example scenario
If you set it to https://signon.aws.amazon.com/saml" like you would for AWS Console SSO, you get an error from the AWS sign in that the SAML response was invalid.
And if you set it to https://127.0.0.1:35001 then you get a message from the browser that the "site can't provide a secure connection".
If anybody gets any further with this, I'd love to hear about it. In the meanwhile, I'm going to be looking into non-AWS OpenVPN clients that might actually support G Suite as a SAML IdP.
#alexandergunnarson
Since I don't have the ability to comment (thanks so much for making this easy stackOverflow) I had to edit my answer to get it past the censors.
Unfortunately, we don't have, and probably won't have for some time, G Suite Enterprise because it's too expensive for our startup environment. So OIDP is not a viable option for us now. I figured this would work. Good to know that it does.
I was too having the same issue. In my case, I needed to turn on the two-factor authentication for the account that I was trying to log in with.
I am running a working AWS Cognito service on a frontend application which can successfully do the basic stuff - login, logout, signup, etc..
Right now I am trying to get user attributes through the backend API, such that:
1) The user login in the application and gets a JWT.
2) The JWT is being sent to the backend server.
3) The server has to extract the email of the user by using the access token
The closest thing that I found to what I need is this Cognito service.
So I am making a GET request to "https://mydomain.auth.eu-central-1.amazoncognito.com/oauth2/userInfo"
With Authorization Header as they are asking for, but I keep getting this response:
{
"error": "invalid_token",
"error_description": "Access token does not contain openid scope"
}
I have tried searching for this error but couldn't find any explanation about the error.
Thanks by advance
Erez, are you using a custom UI?
Because the custom UI uses flows that are completely separated from the OAuth2 ones (USER_SRP_AUTH, USER_PASSWORD_AUTH). Tokens that are released with these flows are not OpenID Connect compliant (basically they don't contain the openid scope) so you cannot use them to gather user infos (since the userinfo endpoint is OpenID Connect compliant and needs to be invoked with jwts compliant with OIDC standard).
We're also struggling on that, i'm sorry.
I had this exact problem and it was my fault. I was sending the id_token instead of access_token property of the token.
I program in PHP, so I was sending as header "Authorization: Bearer ".$token->id_token instead of "Authorization: Bearer ".$token->access_token. Now it works.
Hope it helps you or someone.
I am still experiencing the same issue. My problem relies on programmatic use of signIn service (not Hosted UI via federated login) in Amplify framework. After a long googling, I have discovered that this is because "openid" is not including in the scope of token. Only "aws.cognito.signin.user.admin" is included.
You can find a reference here, thread is still open https://github.com/aws-amplify/amplify-js/issues/3732
This solution seems to be fine for me How to verify JWT from AWS Cognito in the API backend?
If I understand correctly, you are successfully getting the #id_token sent to your front end from Cognito (steps 1-3). You can enable scopes on the #id_token by selecting the following options in your Cognito Pool App Client Settings:
I had a similar issue and I spent a couple of hours to find a solution. The access token you received it from cognito in your frontend application you need to send it to your backend then decode it and verify it. here is a good documentation from aws: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
Able to get only,
{"sub":"u003#tenant.com#carbon.super"}
Things done :
Not able to choose dialect in claim configuration in Wso2-IS 530
WSO2 IS 5.1.0 as OAuth/OIDC IdP response with different claims on UserInfo endpoint
Issue : https://wso2.org/jira/browse/IDENTITY-4463
Tried mapping claims & oidc etc .. nothing seems working : ref
Can some one help me out ?
Update:
call is made to
https://localhost:9443/oauth2/token?scope=openid
Environment is "milti-tenant", I am basically trying to getUserInfo who resides within a domain, not a user from admin.
For a valid token, even the claims are not being fetched under service calls..: reference Oauth2 validation
I am trying to authenticate a user from a custom web app with an OpenID Connect Service Provider within WSO2. I am following an answer on this article and added the Nuget package Thinktecture.IdentityModel.Client. My code is very similar to the linked article:
var client = new OAuth2Client(new Uri(serviceProviderAuthorizeUrl));
var url = client.CreateImplicitFlowUrl(
clientId,
redirectUri: redirectUrl,
scope: scope,
nonce: Guid.NewGuid().ToString());
Response.Redirect(url);
The url comes out to be: https://{wso2_url}/oauth2/authorize?client_id={my_client_id}&response_type=token&scope=openid&redirect_uri=https%3A%2F%2F{mydomain}%2F{my_app}%2FCallback.aspx&nonce=f0db4eac-18df-46f6-92f1-c28ba621596d
Now this does work and returns an access_token: https://{my_domain}/{my_app}/Callback.aspx#token_type=Bearer&expires_in=970&access_token=067e3366217798986912326a86abd92f
My issue is that I have no idea who the user is. Further more, this WSO2 article shows that if I pass a response_type:id_token I should be able to decode the response and find out who the user is by using the "sub" attribute but I am not getting the id_token response. The code above creates a url with a response_type of token instead. Simply changing the response_type gives me an error. How can I use implicit flow in WSO2 and get the id_token response?
I followed this article for the configuration of WSO2. I currently have Implicit and Client Credential checked.
Make sure you have these as query parameters.
response_type=id_token
client_id=xxxxx
redirect_uri=http://xx.com/xx/x
nonce=xxxx
scope=openid
Make sure that you pass on the scope intended to use for the Idp (WSO2) to know what data it needs to return. Make sure your scop
scope=openid.
I installed v5.1.0 of wso2 identity server and executed an OpenID Connect flow. Finally, I wanted user profile information to be retrieved from the server (via /oauth2/userinfo endpoint).
In contrast to other mailings, I only receive a one-item-answer { "sub":"admin }. By default, there should also be phone_number, email and others. It used the playground2 application to verify and yes, only { "sub":"admin" } is returned.
I used scope=openid for the authz code request as well as schema=openid in the /userinfo query as in the descriptions.
I tried to set various claims in http://wso2.org/oidc/claim to supported, required, etc. but no change.
How to I configure the server to return more details?
Any ideas?
This seems to be a known issue in Identity Server 5.1.0 and this is reported here. You can follow the discussion and try applying the fixes as patches to identity server. Other wise you can try 5.2.0-M1 or a later version which this issue has been fixed.