I am testing some workflow in azure on which I have some web apps api connecting to a SQL Database using a service principle. Everything works fine and the web app is able to connect to the database using Managed identity. To test this approach, I also disabled (in the server => Azure Active Directory) the access using username and password and setting the admin group to be able to connect to my server using MFA. All this works just fine.
Once implemented this, I realise that my postman is not able anymore to perform any action. And if I try to send a GET or POST request to the api, I get the error
{
"response": {
"code": "unauthorized",
"reason": "User is not authenticated."
},
"statusCode": "unauthorized"
}
Which is fully understandable as I removed the access using username and password and enable only Azure active directory.
Here is my question, and I hope you can help me with this.
How can I grant access to postman to query my service using a service principle and what is the best approach to achieve this?
Thank you very much for your help and please if you need more info just let me know
The familiar approach for this problem is performing "Get Azure AD tokens by using a service principal".
Performing provisioning a service principal in Azure Portal.
Get AD access tokens.
Use the service principal’s Azure AD access token to access the Databricks REST API
Check the below documentation for step by step procedure.
https://learn.microsoft.com/en-us/azure/databricks/dev-tools/api/latest/aad/service-prin-aad-token#main
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.
while using wso2is-5.6.0
"travelocity.com" application is configure with wso2 identity server to authentication from Facebook am getting this error
org.wso2.carbon.identity.sso.agent.exception.SSOAgentException: Signature validation failed for SAML Response
after google search there some mention that upload certificate file but am not getting this point which certificate file and from where i will get certificate file to upload in identity provider in wso2 identity server
This happens because, your travelocity sample doesn't have the certificate which is corresponding to the key used by Identity server to sign the SAML response. One of the easiest options is to replace the key stores of your travelocity sample with the ones inside WSO2 identity server (Assuming you are using out of the box setup). You can find the key stores in your identity server distribution /repository/resources/security directory. Copy two key stores (wso2carbon.jks and client truststore.jks) to your /WEB-INF/classes. (yes you need to replace existing ones).
Or else if you have changed keys in your wso2 IS, the proper way to do fix this is, export the public key from Identity Server (from wso2carbon.jks) and import it to both (wso2carbon.jks and clinttrustore.jks) in travelocity sample. You can use keytool commands to achieve this.
We recently migrated (registry and user store) from WSO2 IS 5.0 to WSO2 IS 5.1 as per instructions at WSO2 migration guide. After migrating and successfully bringing up the WSO2 IS server, when we are trying to authenticate existing user with /oauth2/token endpoint the authentication is failing. We can see user along with user attributes in user store.
On WSO2 server we are seeing error -
{org.wso2.carbon.identity.oauth2.token.handlers.grant.PasswordGrantHandler} - Token request with Password Grant Type received. Username : <username>#carbon.superScope : openid, Authentication State : false
This is migrated user so we can not change the user name. I tried googling to disable the multi tenancy with 5.1 as we do not use that feature, but no luck.
This is blocking us from moving to newer version of WSO2.
Has Any one fixed this?
Modified the SP to disable domain name as per instructions from Gusto2 -
enter image description here
But still same results.
on the duo identity provider configuration page, under federated authenticators, put "true" in the "disable tenant domain" box
This solution may help. You can go to your identity server and navigate to the service. Now click on edit button of your target service and go to Local & Outbound Authentication Configuration section and uncheck following options-
Use tenant domain in local subject identifier
Use user store domain in local subject identifier
I am showing in the image. Follow the red mark box -
I developed a webapplication Example1:7575 which uses FBA. Now, I deployed these WSP's to a new server Production:2525 to get the same functionality of my previous server's webapplication. However, I was not able to fetch the data from sql server and I'm getting the following error: A Membership Provider has not been configured correctly. Check the web.config setttings for this web application.
Actually, I have manually entered the same membership and role providers of my previous server's central admin, security service token & web application's web.config entries to this new web.configs and matched them.
Can someone help me with where I might be doing wrong. Any help would be greatly appreciated.
If you can't fetch data from SQL Server there's probably an issue with permissions to the database. Check the database connection string that FBA is using. It likely uses Windows authentication to connect - in which case it will be connecting as the user assigned to the app pool for the web application and the secure token service. Check that the configured app pool identities have permissions to access the sql server databases.