I have synchronised AD with keyclock and imported the AD users in Keyclock. I want to login with the CSP user even if CSP VM is unreachable.
I am able to see the CSP user in list of keyclock user.
If CSP is reachable then Able to login also. But if CSP server sudden got shut down in that case I want to proceed with the user.
Please help me.
I tried to generate the access token but for CSP user its not generated , for keyclock user it's generated.
Related
I'd like to use Keycloak to have SSO between my websites and a chrome extension. I've already set up two websites that share the same session and only require the user to login once.
However, when I'm trying to add authentication to my extension using chrome.identity.launchWebAuthFlow(), it does not seem to check cookies for SSO and systematically prompts the user to login, even though I'm already logged in my other sites.
I've tried to do things "by hand" using chrome.windows.create(), and it does skip login credentials to redirect me directly if I'm already logged in from another site, so SSO seems to be working that way. Unfortunately I don't know how to catch the redirection event that occurs once login is complete and then go back to my extension, so I'm stuck on this lead as well.
Do you know if it's possible for the chrome.identity.launchWebFlow() method to check cookies and only prompt for login credentials when it detects no session cookies ?
I have got forms authentication working in my website. But one thing I don't understand. I had a test website and a production website, both using identical database and code. When I logged into the test site, then try to go to the production one, I still need to login. Why?
I thought the login mechanism is this:
After user password is checked fine, the server insert a FormsAuthenticationTicket cookie into client's browser.
When browser attempt to go to a page that requires login, the server checks that cookie. If it is there, then it sends that page.
If my test site has placed that cookie into the browser, now that browser goes to the production site, how did the production site know "I didn't place this cookie and therefore I still require you to login"?
I found out. Because the authentication cookie is only visible to the website that inserted it. A cookie inserted by "www.mysite.com" is invisible to "www.othersite.com".
We are currently having problem allowing a user to a specific URL without logging in in Azure AD authentication.
We are successful in getting token and using it for our API's. But we are currently having problem allowing user to access a URL without them logging in.
What we have tried so far was this links
https://learn.microsoft.com/en-us/graph/auth-v2-service
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Thanks!
In your second link, in the azure portal-> your app service -> authentication and authorization screen, make sure the "action to take when request is not authenticated" is set to allow anonymous. if you set that option to "log in with active directory" that forces authentication on every page no matter what. And ensure in your code that page doesn't require login eg.remove the [authorize] tag.
I have deployed the OIDC provider-keycloak in a k8s cluster and it is exposed as a load balancer.
I'm using this along with Istio to redirect back to my application after successful login in keycloak.
The application is accessible at https://<istio-ingressgateway-ip>/hello
When I hit https://<istio-ingressgateway-ip>/hello, it is correctly re-directing me to Keycloak login page at https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
However, after entering the username and password for the user, I'm not able to get the redirection back to my application at https://<istio-ingressgateway-ip>/hello.
I think the user set up is correct as I'm successfully able to login to the keycloak user console at
http://<keycloak-ip>/auth/realms/<realm-name>/account
I have configured the below values as the 'valid redirect URIs' in keycloak client:
https://<istio-ingressgateway-ip>
https://<istio-ingressgateway-ip>/hello/oauth/callback
https://<istio-ingressgateway-ip>/*
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth/oauth/callback
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
Can please someone let me know what is missing here for the redirection.
Assuming you are using Authservice for the authentication and that your configuration is correct. I had the same issue and when I looked at the logs from the authservice container in my pod, I got to know that authservice failed to obtain the access token in exchange with the authorization code. The issue, as stated by Ryan from Authservice was:
When the Authservice tried to gracefully shutdown the TLS connection, and the server on the other side did not participate fully in the graceful shutdown.
This issue now has been fixed, and you can build a new docker image from the master branch to be able to fix it. More details about the issue and its resolution can be found on this github issue.
If in case this is not the issue, then there could be a problem with the flow from keycloak, you can use OpenID debugger to get the authorization code and then you can use that code to get the access token. This will help you identify if there is an issue on keycloak part.
If your configurations are correct and the above fix doesn't solve your issue, you should consider creating an issue on github with the logs from your authservice container.
I have started maintain a number of websites that are all authenticated using openam SSO. However when one of our users sets a persistant cookie (DProPCookie) it doesn't always work.
Repro scenario is:
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Go to site B, user is presented a login page (they should be automatically logged in).
After step 3, if I delete the iPlanetDirectoryPro cookie from my browser I can login to site B fine (using the persistant cookie). It seems that the iPlanetDirectoryPro cookie generated from Site A when the DProPCookie is set doesn't work on Site B.
Note that I have tried with various permutations of Site A and B and the scenario is the same in each case.
I'm quite new to openam so any hints as to how to debug this would be great or if I'm missing something obviously going wrong please do let me know.
Thanks in advance.
EDIT:
I have subsequently discovered that the iPlanetDirectoryPro cookie returned when authenticating using the DProPCookie isn't working. So thus has nothing to do with cross domain.
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Delete all cookies except iPlanetDirectoryPro cookie
Refresh page - asked to login
If I repeat the test but with the iPlanetDirectoryPro cookie generated by a normal login then when I refresh the page, I automatically get authenticated. (I have changed the title of the question to reflect this).
FURTHER EDIT:
Turned up debugging - am seeing this exception in the logs:
IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)
A quick scan through the openam code - it appears that we are not getting a username here in AMAccountLockout.java:264:
public boolean isLockedOut() {
// has this user been locked out.
String userDN = loginState.getUserToken();
return isLockedOut(userDN);
}
Persistent Cookie mode has changed in OpenAM ... DProCookie is actually not used anymore.
Posssibly you're running 'restricted token mode' AKA 'cookie anti-hijack mode' and CDCServlet does not issue a proper authentication assertion
Could be that you are running into https://bugster.forgerock.org/jira/browse/OPENAM-1002 ?
Also it could be a problem with your cookie domains, maybe site B redirects to a different domain where DProPCookie is not visible?
Ultimately we discovered that the problem was that the SSO cookie generated by the persistant cookie had no authention modules - and therefore the authentication level was set to Integer.MIN_VALUE;.
In our situation we made a slightly hacky fix to force this to be 0 instead, which fixes up the problem.
I presume the correct thing to do would be to either have a seperate authentication module for persistant cookie logins or to store the authenticating module in the SSO cookie generated by the Persistant cookie.