I have user in wso2 Identity server , say "abcd" (In Primary domain), configured LDAP domain Also. but there is no user with "abcd" as Id.
when I try to login for Wso2 IS management console Initially it will show as Signed-in as:abcd#carbon.super , but after some time it is showing as Signed-in as: LDAP/abcd#carbon.super.
Mostly we saw when we try it from more than one console with same user name.
why this error?, any known bug or feature?, I'm using wso2 IS 4.5.
Actually we are not aware about such issue. Thanks for letting people know about this. Did you experience any issues with the functionalities? Or this is just only show in the UI... AFAIK, this Domain name append to user name, user session contains an some attribute called "DoomainName". I guess, some how this value may have been set in to the session.
Related
I'm trying to create an App which has a log in page where user should be authenticated using azure AD. Basically the App has a log in form where user puts his id and password from ad and django should check with ad and allow him in or not. Later on ofc would like to add permission depending on AD group.
So far I searched a lot on the internet and found nothing. Could you guys help with some example or link to documentation what I could use.
First of all, I'd like to suggest that you don't do that.
What you are asking for is ROPC flow: https://joonasw.net/view/ropc-grant-flow-in-azure-ad.
Usage of this flow is not recommended unless this is for migrating a legacy application (which is the original purpose of ROPC).
It also won't work if the user has MFA, an expired password etc.
There is usually no reason why you'd want to handle user passwords when using a federated identity provider.
I'm following the "Gauth authentication" portion of Djangae's documentation but I'm running into some unexpected behavior.
I've configured urls.py and settings.py as specified by the documentation (the current settings are mostly a result of using the Djangae Scaffold) but at no point are users prompted to authenticate using or link their Google account. I've tried un/setting DJANGAE_CREATE_UNKNOWN_USER but this has no impact.
I've also tried running commands inspired by sitepackages/prod/djangae/contrib/gauth/tests.py in my local shell in order to verify that the back-end configuration is correctly configured and that users can actually be authenticated against AppEngineUserAPIBackend but that fails because my User model (djangae.contrib.gauth_datastore.models.GaeDatastoreUser) seems to be missing required attributes: AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.
So, am I misunderstanding how this is all supposed to work and must take some additional steps to get Google Sign-In working? Or have I (likely) misconfigured my application? (I'm happy to include genericized versions of my config, but as I said, they've come directly from Djangae Scaffold or the documentation.)
UPDATE: Interestingly, if I remove the --headless flag from my Behavior suite config, I see the expected behavior. The browser (Chrome) is being redirected to https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F
Environment:
Djangae (0.9.11)
Django (1.11.19)
It turns out that this is the expected behavior. In the local sandbox, users are prompted for an email address and (by default) a "user" is created for them and they are automatically logged in.
From App Engine's "Users Python API Overview" document:
Google accounts and the development server
The development server simulates the Google Accounts system using a
dummy sign-in screen. When your application calls the Users API to get
the URL for the sign-in screen, the API returns a special development
server URL that prompts for an email address, but no password. You can
type any email address into this prompt, and the app will behave as if
you are signed in with an account with that address.
The dummy sign-in screen also includes a checkbox that indicates
whether the dummy account is an administrator; that is, whether the
account has the the Viewer, Editor, or Owner primitive role, or the
App Engine App Admin predefined role. If you check this box, the app
will behave as if you are signed in using an administrator account.
Similarly, the Users API returns a sign-out URL that cancels the dummy
sign-in.
The unique ID for a User object in the development server is
calculated from the email address. Two unique email addresses always
represent two unique users in the development server.
Personally, I think this design is very flawed. I don't know what Google thinks about the Twelve Factor manifesto, but this behavior is a flagrant violation of article 10 (Dev/Prod Parity), which is summarized as "Keep development, staging, and production as similar as possible". I see no reason why the full auth/redirect flow wouldn't work in the local sandbox and, at the very least, users should be able to opt into it. (I would love to find out that this is an option.)
The most concerning part about this conditional behavior is that the user object's API is different, which is why I was seeing the error mentioned in my question ('GaeDatastoreUser' object has no attribute 'user_id'). The local user also has no nickname method.
We are using WSO2 for authentication (SAML/SSO).
I don't know how to tell if a user is already logged in (in order to prevent concurrent logins). Other SO questions have indicated this is possible to know both with WSO2 IS Analytics and without. I would prefer to not have to run WSO2 IS Analytics as well (this is alluded to here, but never clarified. Further, I can see the IDN_AUTH_SESSION_STORE table being populated and referred to during login, but that is using SESSION_ID (which is passed by the commonAuth cookie).
So I'm looking for a direct answer to this question: during the Auth flow, how can we tell if the given user is already logged in?
Without using the analytics, querying logged in user sessions by a user is not supported out of the box in WSO2 Identity Server. Let me explain why.
When a user authenticates with the WSO2 Identity Server, a session is created. These sessions are stored as session context objects, against the commonAuthId cookie in WSO2 implementation. Information about the logged in user is inside these session objects. Therefore if we want to get the session for a particular user, we have to query all active sessions and go through all of them one by one matching the user.
As an alternative, you can write a custom data publisher module which persists session data against each user and then you can use these data to prevent concurrent logins. I have a blog post written for this exact use case.
Hope this helps.
I've created a Glass app in Python. I began with the mirror quickstart for Python and have my app running fine except some users are getting multiple notifications. I only have one row per user in my Credentials table, however when I go and look at my own Authorized Access on my account I see that I have my Glass project listed 8 separate times.
Can anyone tell me how to check and see if the user has previously granted access to my app when they sign in and if so then skip creating a new token.
You can use the user's ID to prevent storing more than one credential for each user.
When you complete the OAuth flow, you'll receive an ID token along with the access and refresh tokens. If you decode this token, you'll see something like this:
{
"iss":"accounts.google.com",
"at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q",
"email_verified":"true",
"sub":"10769150350006150715113082367",
"azp":"1234987819200.apps.googleusercontent.com",
"email":"jsmith#example.com",
"aud":"1234987819200.apps.googleusercontent.com",
"iat":1353601026,
"exp":1353604926
}
The sub key is the one you're interested in. Use this value to uniquely identify your user. If you see a user authenticate with a user ID that you already know, replace the old value.
If you update your question to include the code you're using for your OAuth flow, we can provide more specific advice. Or, you can learn more about this from Google's OAuth documentation.
I am working to set up SSO for our intranet the idea is that a user would login to their workstation using their active directory username and password. Then a small application would run at login that would send some uniquely identifiable information,user name, and computers MAC address to the server were it would be entered into a database with a time stamp. Then when the user accesses the intranet a java applet would send the users mac address to the server and compare it to the database entry to see if it finds a match within a given time frame, if it does then it signs the user in and removes the entry from the database.
Unfortunately our intranet is not running on IIS so I can't use NTLM to do authentication which would be easier but not cross browser compatible which is one of the requirements. NTLM is also not an option because our intranet is only accessible in the form intranet.company.com and as far as I know NTLM does not work with addresses in that form.
Okay now onto the question. I am currently in the process of creating the client authentication application in C++ and need a way to get some unique identifier or token that would differentiate a legitimately logged in Active Directory user from some one who got a hold of the application and changed their local username to an AD user.
Yes I know this is probably the wrong way of doing it but right now it seems like the only option. If you have any suggestions beyond not doing it please let me know. Also I am aware of the huge gaping security hole it creates if you can think of a way to patch up that hole with out NTLM be sure to let me know.
AD is just Microsoft's implementation of Kerberos. One of the core features if Kerberos is to create such permission tickets. So, on that side your solution is not a hack at all. It's just the validation part that looks like a car crash.
However, I'm entirely lost at the client-side problem you have. The entire point of AD or Kerberos in general is that you can't spoof an authenticated user. You just ask the OS for a ticket for the logged-in user. It doesn't matter who gets hold of your app, or or what his local username would be. The OS knows precisely who is logged in.