As per the Keycloak manual, the Kerberos authentication flow should be like:
https://www.keycloak.org/docs/latest/server_admin/#configuring-a-kerberos-storage-provider
A typical use case for web authentication is the following:
1. User logs into his desktop (Such as a Windows machine in Active Directory domain or Linux machine with Kerberos integration enabled).
2. User then uses his browser (IE/Firefox/Chrome) to access a web application secured by Keycloak.
3. Application redirects to Keycloak login.
4. Keycloak renders HTML login screen together with status 401 and HTTP header WWW-Authenticate: Negotiate
...
However, I'm not getting the WWW-Authenticate header after sending the login. What I'm getting is a 302 (Redirect) to the Realm but with no header !!
Please note the following:
Keycloak
1 - User Federation LDAP configuration in Keycloak works correctly, I can login and sync the LDAP users.
2 - Kerberos integration is set and the keytab file works correctly since I can do LDAP search from the console
3 - In the Keycloak Authentication flow Kerberos is enabled and required.
Client
1 - I had added the server URL to the Internet sites.
If you have any idea why the [WWW-Authenticate: Negotiate] header is not being sent I'll appreciate it.
Related
Szenario: Browser user is authenticated (single sign-on) on a Windows web server. On this server, a VisualBasic program should be accessing an application on another server with the current Kerberos credentials of the SSO user.
Question: How can I obtain a TGT ticket in VisualBasic (or pure Java) and extract the authorization token to be passed in the HTTP header "Authorization: Negotiate Yll..."?
Background:
I have an application server that has an endpoint of /api/token. What this API does is it performs authentication against the supplied username and password using the standard basic authentication protocol.
When the process is successful, it returns an access token and HTTP code of 200 (OK). When fails, HTTP code 401 (unauthorised) is returned.
Question: Is there any way I can make Grafana's login page to pass on the login credential to my application server for authentication?
No, unless you want to hack source code.
But you can use Grafana in auth proxy mode, where authentication will be made by some "auth" proxy. For example, auth will be made by reverse proxy (e.g. Apache+mod_authnz_external) which will be in front of Grafana. All auth logic will be there and Grafana will just receive the request with request header X-WEBAUTH-USER value when user authentication is successful.
Another option is to start OIDC Identity Provider (for example Keycloak), which will use your app auth endpoint for authentication. Grafana has native OIDC/OAuth support, so it will be just configured against your OIDC Identity Provider.
I've setup apache reverse proxy for my application with ldap authentication.
The problem is that the backend application also requires authentication.
After I entered ldap credentials, it always returns 401 and doesn't prompt for the application authentication.
The backend uses different credentials.
Assuming that the backend-server uses the very same LDAP authentication as the frontend you might want to have a look env var proxy-chain-auth in docs for mod_proxy_http.
I'm trying to use the authenticationendpoint application that comes with WSO2 as the new only login entry point of an old application. For testing purposes I just did a page that redirects to thi URL
https://localhost:9443/authenticationendpoint/login.do?relyingParty=My-Issuer&sp=Test-App&sessionDataKey=14792551&authenticators=BasicAuthenticator:LOCAL
The login page appears as expected, but once I set the user and password shows this message:
Authentication Error !
Attention:
Something went wrong during the authentication process. Please try signing in again.
Seeing the output in the console on debug mode, this is what is shown
... Many of the same error saying that Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,837] DEBUG {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Session data key : 22451696
[2017-01-06 15:40:08,837] ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
I thing I'm doing something wrong, maybe there are not enough parameters sent, or they are the wrong ones, the user and password are correct because I can login into the carbon itself with it, and it is also a valid user for the testing SP.
The SP config is described:
Basic Information
Service Provider Name: Test-App
Claim configuration
Use Local Claim Dialect
Subject Claim URI http://wso2.org/claims/username
Role/Permission Configuration
Permissions AdminTest
Role Mapping AdminTest->Admin
Inbound Authentication Configuration
SAML2 Web SSO Configuration
Issuer: My-Issuer
Assertion Consumer URLs: https : //localhost/Test/main.asp
Default Assertion Consumer URL: https : //localhost/Test/main.asp
NameID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Certificate alias: wso2carbon
Response Signing Algorithm: ...#rsa-sha1
Response Digest Algorithm: ...#sha1
Checked values
Enable Response Signing
Enable Single Logout
Enable Attribute Profile
Include Attributes in the Response Always
Enable IdP Initiated SSO
Enable IdP Initiated SLO
Others are in blank OAuth, OpenID, etc (let me know if that is maybe the problem, so which should be filled out.
Local and Outbound Authentication Configuration
Authentication Type: I tried with Default and Local Authentication = basic and password-reset-enforcer
This is checked:
Assert identity using mapped local subject identifier
Use tenant domain in local subject identifier
Use user store domain in local subject identifier
Request Path Authentication Configuration
basic-auth
Inbound Provisioning Configuration
SCIM Configuration
PRIMARY
Dumb Mode is not enabled
The rest is left blank
I have spent many days tracking this problem but no answers or are for older versions.
I tested with JDK 7 and 8 (latest of them) I'm working with WSO2 IS 5.2.0. Someone can lead me to a solution to use this application as the only entry point for my SPs? The idea after is to send back a SAML2 response to a page in the SP side that read the information and control the authorization part.
Thanks in advance.
You have configured for a SAML SSO scenario. Therefore your SP have to call the SAML SSO endpoint of WSO2 Identity Server with a valid SAMLRequest. That is https://hostname:port/samlsso.
AuthenticationEndpoint is just an intermediary application. SAML SSO endpoint is the one that should redirect the user to AuthenticationEndpoint after first processing the SAMLRequest. You must not call it directly.
Refer this to learn how to run a sample SAML SSO application with WSO2 IS. While running that, you can monitor the HTTP Request/Response flow using a tool like SSOTracer for Firefox and understand how the communication works.
In similar to SAML SSO flow, if you are using any other authentication protocol, you first have to call the protocol specific endpoint. E.g. If you are using OAuth2 or OpenIDConnect, then you should call /oauth2 endpoint. Never /authenticationendpoint directly.
I am working on implementing WebSeal single sign-on so that the user does not have to enter credentials for a particular web application if the user is already logged in via Windows authentication. Can anyone please point me in the right direction. I am new to Web Seal
WebSEAL has something called junctions. You can create webseal junctions and configure it to application webservers. Suppose if your SSO solution involves 3 applications, three webseal junctions has to be created. Webseal will act as reverse proxy in this case. So when a user trying to access anyone of the application, He will be challenged with a login screen from webseal. User will be authenticated against LDAP(u need to map your ldap in webseal) and his session will be maintained at webseal.Once authenticated user information will be sent to application servers via junction in HTTP headers. Now when user access other two application, he will not be challenged with authentication. His information will be sent to application servers directly via headers as webseal maintains his session.
For more info:
https://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1359-00/en_US/HTML/am51_webseal_guide16.htm
WebSEAL supports Windows single sign on using SPNEGO protocol & Kerberos Authentication. Read this link for configuration steps:-
https://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1359-00/en_US/HTML/am51_webseal_guide78.htm#sso-windows-desktop