Okta will always gives the previous guest user session when I try to login with another user. Is it possible to end the okta session from azure?
In my iOS application, I introduced Okta as an External Identity by using SAML. All of this is functioning, but when I attempt to log out a guest user, the user will leave Azure, but their Okta session will remain open. As a result, Okta will always gives the previous guest user when I try to login with another user. Is it possible to end the okta session?
Please accept my gratitude for any assistance or advice.
Would suggest reaching out to the Okta Support Team would help here, to see if their engineers and community can take a closer look into your issue.
For reference you can refer to okta documentation related to sign out behavior.
Reference: https://learn.microsoft.com/en-us/answers/questions/1089192/is-it-possible-to-end-the-okta-session-from-azure.html
Related
I didn't quite understand the logout process in AD.
Say a user logs out from other app (not mine) that's connected to AD, would my SP get called when it happens?
Another thing that i'm missing is, what happens when user was removed/deactivated from their directory? how would I know when to clear their session? couldn't find anything regarding this issue in AD's docs.
The following diagram shows the workflow of the Azure AD single sign-out process.
If the user logs out from one app connected to AD(the same tenant as yours), he will be signed out from other apps connected to the same AD.
If a user was removed from their directory, the user will get an authentication issue.
In our environment someone have changed the user Sign-in method to Password Hash through synchronization from federated with ADFS, although it did not have any impact as users are still authenticating with ADFS succesfully. But now we need to change it back to Federated with ADFS. There is not much documentation on what will be impact or if the trust and claims will be modified if we change it. Any help will be appreciated.
It appears that it is a simple switch.
Note the point about cache issues.
And always good to have backups!
I have an existing J2EE application which provides some specific features after logging in to the application.
I have to provide SSO to just ONE of the customer who logs into our application while the rest of the customers would still use the login page and login with their credentials.
I am planning to use OpenAM Fedlet act as SP deployed as a separate application in our container.
I need some help in understanding if i need a full blown OpenAM instance deployed within us. Please provide any insights if you may have on this .
You can use the fedlet as an SP for this user. The trick is identifying this particular user and initiating SSO for this person, and going to the login screen for everyone else.
I am using adal.js in a SPA client to login and acquire access tokens for my web service. We are updating our app registrations with new permissions, which will require users to consent again.
I'm wondering what set of error codes from AAD indicate consent should be asked for as opposed to taking some other error handling action?
To my surprise, I was unable to Google a full reference listing all error codes AAD may return. Is this information publicly documented? I'm referring to the error codes of the pattern, AADSTSxxxxx (i.e. AADSTS65001, etc), which may be returned from the oauth2/authorize endpoint.
AADSTS65001 is the primary consent error that indicates the end user needs to do consent again. I would recommend against looking for specific AADSTSxxxxxx errors and having your app branch off encountering that error. Sometimes these change and there could be new errors in the future that indicate a similar "consent needed" message.
If you're building a single-tenant app, a good option is to perform admin consent when you make a required resource update to your app. You can do this by clicking Grant Permissions in the Azure Portal or sending an Auth request with prompt=admin_consent and signing in with an admin account.
For multi-tenant, there's a few options depending on the app. One option is to build an admin consent experience for updates like this where an admin could go, hit a button that initiates an admin consent request, and then have the admin sign in.
One new feature coming to adal.js that I believe will make the development process a bit easier is the new interactive acquire token call. This will allow you to specify a resource on an acquireToken call that can show UI and will ask for consent if needed. Once this is available, your app can attempt the silent acquireToken request, and upon failure attempt this interactive version. Watch out for this release on Github.
I am trying to get the user who is logged in via. SAML Single Sign On.
I have already implemented SAML Single Sign On and it works.
The code I use for programmatic login is :
apps = gdata.apps.service.AppsService(email=username, domain=domain, password=password)
apps.ProgrammaticLogin()
logging.info("current user %s", users.get_current_user())
//Redirect to a Google mail page.
But users.get_current_user() returns None always even though correct username and password is provided. I have crosschecked it by redirecting the page to Google Mail page and it successfully redirects.
I have googled this issue for hours now nothing goes the right way.
Can anyone please guide me what I am doing wrong ?
There are three different things going on here, I just want to make sure are clear for my suggested answer to make sense:
Google App Engine users service: You, as the developer, delegate authentication and authorization responsibility to Google Accounts (or the selected OpenID provider). Google will act as the Identity Provider and you'll act as the Service Provider.
SAML single sign on: Google delegates to you the authentication and authorization responsibility, you'll act as the Identity Provider and Google will act as the Service Provider. You'll be using SAML SSO every time you try to login any Google service using you Google Apps account, that includes Google App Engine applications using the users service.
ClientLogin: It is one of the methods for authenticating to use a Google API by giving username and password. It's deprecated, it's hard to maintain and insecure since you are hard coding the credentials and the app could have access to everything. I'd recommend switching to OAuth instead. In the first two lines of code You are initializing the Google Apps provisioning API with gdata.apps.service.AppsService, if you are not going to retrieve or create users/groups/alias is useless to do that. If you are I'd also recommend switching to the Directory API part of the new AdminSDK
For your particular case I'd suggest checking if there is a current user logged in, if not redirect to the login URL using the GAE users service.
user = users.get_current_user()
if user:
logging.info("current user %s", user.email())
else:
return redirect(users.create_login_url(request.url))
In case you always require that the user is logged in you better set the handler as login: required
The user will be redirected to the SAML SSO page to log in to his Google Account in order to access the GAE app.