I apologize, in advance - I'm extremely new to Nginx.
I have one VPC-based AWS Elasticsearch Domains
I enabled Fine-grained access control with user type IAM credential.
The domain is in the us-east-2 region while Cognito is in the us-east-1. Authentication via Cognito works correctly. The problem is the logout phase. Clicking on the Logout button does not happen. Performing a check via Console I find the following errors:
Request URL: https:///_dashboards/auth/logout Request Method: POST
Status Code: 302 Found
Request URL: /error Request Method: GET Status Code: 404 Not Found
How can I make Kibana understand using Ngnix that it should invalidate the session and then logout and redirect to the authentication page? Thank you in advance for any help you can give me.
EDIT: SOLVED enabled Fine-grained access control with Opensearch internal user instead of IAM credential.
regards Francesco
Related
I were following the sample provided in OneLogin Developer Portal - https://developers.onelogin.com/quickstart/authentication/java-spring. I did everything described in the article. But on running the application, authentication happens; I were taken to OneLogin page and I enters the credentials. But on redirection, I get following error.
"http://localhost:8081/login" is the redirect url configured in admin portal. And it is the default url which is been passed in the first request.
https://kore-wireless-dev.onelogin.com/oidc/2/auth?client_id=<?>&redirect_uri=http://localhost:8081/login&response_type=code&scope=openid profile email&state=UY6Tam
In the sample code, the endpoint is not implemented. But I don't think application developer needs to implement that endpoint.
I tried Github SSO. Where we can specify different redirect urls in app configuration (spring-security-url) and github sso configuration (app-url). And after authentication github will redirect to spring-security-url. And then that endpoint will redirect to app-url.
Is Spring Security OAuth2 is not compatible with OneLogin? Or what I am missing here.
I have recently faced the same issue. In my case, we had to modify the Authentication Method of the Token Endpoint in OneLogin oidc application. When it was set to Basic, it was throwing the Unauthorised error. Probably, the sample application invokes the OIDC token endpoint with credentials (clientID and clientSecret) in the payload request (POST Auth Method) rather than in request header(Basic Authentication method). Sharing the screenshot of the same here.
When I try to log in to my application it returns the following error:
"Can not Load URL: The domain of this URL is not included in the app's domains. To be able to load this URL, add all domains and subdomains of your app to the App Domains field in your app settings."
How can I resolve this?
The error explains the issue itself. Whatever URL you are using to send the request and expect Facebook to redirect you after user logs in successfully needs to be mentioned in App Domains field in app settings.
I am integrating Drupal and OKTA. When I try to access my website I am being redirected to Okta for login. But after successful authentication I am not being redirected back to my website.
I am following a SP initiated workflow. My log message in OKTA is as follows.
Is there a way I can have more debugging information from OKTA to figure out what is going on and what setting is wrong?
My suspicion is that the target resource in the SAML template isn't correct but several things could be going on. A valuable tool to help debug this is the SAML tracer extension to Firefox.
https://addons.mozilla.org/en-us/firefox/addon/saml-tracer/
It was becuase of the redirect url not set properly in the IDP and the port number issues on my server.
If you are interested in the detailed set up please checkout https://www.youtube.com/watch?v=IEtNUAM79K8
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
I'm writing a web application which requires a user login. As you might recognise there are many workflows for responding on invalid user credentials. Most browsers are captable of storing (accepted) user credentails in their credential storage.
My original question splits up into two parts:
Which HTTP status code should be send to the user if a site requires a logged in user? I don't mean the situation the user is requesting the login page by herself.
Which HTTP status code should be send to the user if he/she has entered invalid credentials?
HTTP 401 is only for the "old style" authentification via browser prompts I guess. I'm using my own login pages to get rid of those browser prompts.
There are many standards for the authentication. Couple of example you can find here:
http://docs.oracle.com/javaee/1.4/tutorial/doc/Security5.html
The error code 401 you described is used for the Basic Authentication. It is not old :).
When you use your own login form please follow the standard Form authentication flow:
If a user access a protected resource without an authentication redirect to a login page (HTTP code 302)
Show the login page (HTTP code 200). Submit a user name to a dedicated URL (generally it is j_security_check)
After a successful authentication redirect back to the original protected resource (HTTP code 302)
After a failed authentication show once again to the login page with the error code (HTTP code 200)
If a user access a protected resource after the authentication show the resource (HTTP code 200)
To distinguish between an authenticated and not an authenticated session you can use HTTP cookie.
It is recommended to use GUID and not any user information (e.g. user name).
401 Unauthorized / 407 Proxy Authentication Required are the only status codes that are relevant.
401 Unauthorized should only be presented if you are denying access to any resource - NOT if you are redirecting or presenting them with a login page.
407 is just like 401 except you are expecting auth to be handled by an external service and you expect to be provided with a Proxy-Authenticate header field.
More typically, you are presenting the user with a 200 OK and a login page.