Brand new, checking out wso2 API manager 1.8.0. I work for a corp with multiple organizations/teams, so setting up multi-tenancy seems like the logical choice.
Following the quick start guide, I first created a new tenant, gave it a domain of "dev.api.myorg.company.net", added some users to it, and I can log in. I added one API.
I am able to hit the endpoint using the URL listed in the store:
http ://wso2server.company.net:8280/t/dev.api.myorg.company.net/apiname/v1/endpoint
But my expectation was that configuring this tenant with a domain would allow me to hit:
http ://dev.api.myorg.company.net:8280/apiame/v1/endpoint
I have pointed the dev domain to the wso2server IP, but when I try to access using the dev api I get:
http://pastebin.com/VNXjEv3y
Am I just missing something completely obvious? Is there extra work to make wso2 allow tenants to point their domains at it?
I have spent the last hour and a half googling and searching through tagged wso2 here, but google mostly points to the wso2 multi-tenant docs page, which is like a single page without any details.
Any pointers to better docs or suggestions for better search terms? Ive tried combinations of:
wso2 multi tenant tenancy domains hosts how to access
when you create an api in a tenant it will get the following url pattern
http ://**<IP-where apimanger is hosted>**:8280/t/<tenantdomain>/<apiname>/<version>/
where 't' denotes this api url is specific to tenant and tenantdomain denotes which denant
but for super tenant url will be as following
http ://<IP-where apimanger is hosted>:8280/<apiname>/<version>/
For tenanants, domain is just a name (not having mapping to ip).So APIM will not work as you expect.Because you need to specify the IP(or domain) where APIM is hosted in the url.
Related
I have some applications served to my company users on EKS (i.e., Jenkins). In company we use Google Workspaces (GSuite) for email and stuff. So I want to allow users to login with Google creds to those applications I serve. I figured out I could use Cognito to achieve it but I cannot connect those and flow end with Google showing 403. Error: app_not_configured_for_user. In their documentation I can find:
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.
but how do I debug it? I do not see a logs from neither AWS and Google sides :/
I think I followed all possible guides and I cannot find what I'm doing wrong. I found that Google has this page but they do not provide exact scenario for AWS Cognito. Anyways all of those are very similar so I guess I shouldn't have problems, but I do have.
What I did:
In Google Admin (one for workspaces) I created "Web and mobile app" of SAML type
I downloaded metadata file
In AWS Cognito console I created User Pool
I created IdP provider and uploaded metadata file there
I created application client
Using those values I filled fields ACS URL and Entity ID in Google Admin using values:
ACS URL: https://my-domain-i-just-created.auth.us-east-1.amazoncognito.com/saml2/idpresponse
Entity ID: urn:amazon:cognito:sp:us-east-1_myPoolId
I also selected Name ID format to be Persisted
In attribute mapping I mapped email value to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
In AWS Cognito I enabled HostedUI and also created mapping of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to email field.
And now when I click View Hosted UI in AWS console it will redirect me to Google authentication and after it directly to before mentioned 403 app_not_configured_for_user page.
I tied it 3 times with slightly different configurations of mapping, signed responses, etc. but nothing gets me past that error.
Anyone tried to integrate it?
How to troubleshoot the 403 app_not_configured_for_user error related to SAML apps from the Google Workspace Admin console
The first thing you need to do is to grab a HAR file recording the whole login process and find the SAML request. Steps can be found here.
Once you get the file you can open it using that tool and search for SAMLreq at the top right (see image).
After that you will get a list of values containing information. You will have to check one by one until you find the one that has the SAML request in the request tab (see example below).
Once you get the value from the SAML request, copy it and you can use this tool to do a SAML decode and find the entity ID. You can use Ctrl + F and search for saml:Issuer to find the value faster. If the value does not match, then you know you have an error and you will need to contact the support team from the app to see which value is the correct one.
In case the value matches I would recommend opening a ticket to check with Google.
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.
My team is trying to expose WSO2-IS through a reverse proxy. With our team setup, each new application is exposed under a single context-root, and we're hoping to do the same for wso2.
Using the oauth2/authorize endpoint as an example, we would like to expose the endpoint through our proxy as
https://<domain name>/wso2-is/oauth2/authorize rather than the default
https://<domain name>/oauth2/authorize
It turns out we would need this same configuration for a number of webapps under wso2is, including:
oauth2
oidc
commonauth
logincontext
authorizationendpoint
I've found information online for how to do this with the admin console, but I haven't found any info on how to do it for these public endpoints.
Has anyone been able to accomplish this, or does someone know whether or not WSO2 was built to support this use case?
You can follow the official documentation on Adding a Custom Proxy Path.
I am setting up a WSO2 Identity Server at the moment . The first step was to use the resident identity provider in super tenant and setting up service providers as SaaS applications. This worked pretty nice so far.
The bad thing about it is that (1) users need to login by identfying themselves using the username#tenantdomain schema. The next bad thing about it is, (2) that we can not configure login policies or account management policies per tenant. We only can handle it globally.
For testing reasons we modified the authenticationendpoint application to inject the tenant domain on the fly while logging in (by analyzing relyingParty parameter). This worked so far, but point (2) still remains.
Next step was to configure an IdP and SPs per tenant. For my understanding that is the way to get rid of points (1) and (2).
That is where I am completely stuck. The carbon log only mentions that we need to register the SPs in advance. I am reading various posts, jiras issues and blog entries for the last week but I still do not have a working solution. Seems to me that even though I configured the tenants resident IdP and exchanged metadata accordingly the IS still thinks we are trying to communicate with the super tenants resident IdP.
The SPs we are using are created using SimpleSAMLphp.
Maybe I missunderstood the principles of setting up IdP/SPs per tenant in WSO2 IS? Maybe I am handling the resident IdPs the wrong way?
Any help/advice is welcome.
Even though this question is old, below part from the documentation will help whoever searching for an answer.
From WSO2 Identity Server 5.0.0 onwards, there are different SAML
endpoints for each tenant. If the service provider calls the identity
provider's SAML endpoint URL as
https://is.com:9443/samlsso?tenantDomain=foo.com or the issuer name is
appended with #<TenantDomain> like travelocity.com#foo.com, the SAML
requests are directed to the foo.com tenant.
Additionally, note that when using SAML SSO with a tenant (using either of the above methods), the SAML response is signed with the private key of the particular tenant.
I would like to share web service which is deployed in super tenant to other tenants. As far as I know everyone can access the super admin services if they are using http:// localhost :8280/services/echo?wsdl url. But I do not want just to access super tenant application, I would also like to see request count on correct tenant. Should I have to deploy the same application to every tenant and call service with proper url (http:// localhost .com:8280/services/t/tenantname/echo?wsdl) to collect the request counts?
Is there any other way to do this? For example maybe I could put header variable to my request which is showing, which tenant is calling the application etc., and with this kind of approach, I do not have to deploy my service to other tenants.
You can use a code something like,
int tenantId = MultitenantUtils.getTenantId(this.getConfigContext());
to get the tenant ID of the current tenant and send it either in the message itself or in the header. Then you can record the tenants accessed in the server side, by counting the tenant IDs.
This will help you to get the tenant ID.
One possibility is to deploy the application at each tenant. Then you get a separate URL for each.
Or else you can make your service multi tenant aware. For this you need to make the service secured. When log into the service, we can determine the tenant using the user name. For an example foo user should be a super tenant user while foo#bar.com should belongs to bar.com tenant. In this case carbon framework, does this authentication and set the tenant details to carbon context. You can access that at the service level. eg. CarbonContext.getCurrentContext().getTenantID() or with the method Maninda has mentioned.
org.wso2.carbon.tomcat.ext.internal.Utils class has a function which name is getTenantDomain.
I have changed this methods to find tenant domain from headers, so it is working like a charm :)
I think WSO2 also thinks to customize this method.