Windows Live ID seems to be giving back a different User Token for the same User on different Apps.
Heres the scoop.
Windows Live ID is supposed (i think) to give me Unique User Token.
I want to use this to identify the user.
My App is 2 parts ... 1 = ASP.NET webapp...2 is WPF.
(Same DB / User Table)
Problem:
When user logs in to ASP.Net - I get UserToken = 00202009399.
When user logs in to WPF - I get UserToken = 00829909233.
Question:
Is this a glich? If so - what is a
work around?
(If this is planned behaviour - I can only think MS wants to separate User Tokens per Application or Domain)
Is there a setting to Tell LiveID
that these 2 differnt Apps (WPf &
ASP.Net ) are from same
Orginization/Owner/Azure Account?
I know this answer is late in the game. Windows Live ID provides you with a unique, site-specific identifier for each Windows Live user who signs in to your site. It is designed that way to allow user confidentiality and security from one site to the next.
Is there a setting to Tell LiveID that these 2 differnt Apps (WPf & ASP.Net ) are from same Orginization/Owner/Azure Account?
If you want the to have the same identifier you will have to use the same App Id. If you are wanting to maintain the part of the application you are signing in from you can use the context Parameter to set the path to return too the only requirment is that they have to be in the same Domain you set when registering your application.
Related
I was trying to access user information like first name, last name of the user in my ASP.NET Core MVC project with Windows authentication. I actually make it work after searching for a solution on the web but I am quite new to this stuff and beginner level programmer so not understanding what is happening in the part that I just copy paste in my project.
I couldn't find any explanation in that website as well. I would be really happy if someone can explain this to me. Many thanks in advance.
The website reference for this code: https://sensibledev.com/how-to-get-user-details-from-active-directory/
Home controller:
var username = User.Identity.Name;
using (var context = new PrincipalContext(ContextType.Domain, "yourdomain"))
{
var user = UserPrincipal.FindByIdentity(context, username);
if (user != null)
{
ViewData["UserName"] = user.Name;
ViewData["EmailAddress"] = user.EmailAddress;
ViewData["FullName"] = user.DisplayName;
ViewData["GivenName"] = user.GivenName;
}
}
That code takes the username of the user who logged into your website and looks it up on your domain to find more information about the person.
var username = User.Identity.Name;
The User property is ControllerBase.User, which refers to the user currently logged into your website. Since you're using Windows Authentication, this will refer to an Active Directory user. User.Identity.Name gets just the username.
The rest is for looking up the account in Active Directory.
new PrincipalContext(ContextType.Domain, "yourdomain")
This means "I want to talk to a domain called yourdomain".
UserPrincipal.FindByIdentity(context, username)
UserPrincipal.FindByIdentity finds an account on the domain. So this is saying "find this username on the domain".
Then the users details from the account are put into the ViewData collection so that the data is accessible in the view. More details on that here.
From your website's perspective, all Windows code runs under some Windows account.
If you use IIS and Forms authentication for example, then Windows knows nothing about you - you are likely to be running under an anonymous account name which all users will run under. If you drill down through your running code, it is possible to find different Windows accounts at different code levels, such as in your top level code, the underlying IIS thread, etc.
You are trying to use Windows accounts for your web site but you have to ensure that the web server it is running on is also using Windows Authentication - I know you checked this option when creating your site.
Your user identity can be cast to various types because it has to work seamlessly whichever authentication methodology is in use. You can also check your user to see if it is of a particular security regime.
Have a look at https://learn.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.1&tabs=visual-studio
You get the security principle information using
var context = new PrincipalContext(ContextType.Domain, "yourdomain")
PrincipleContext is the class that has the information once you create a new instance of it, passing in parameters for the type of domain (an enumeration) and the name of your domain (a string).
The USING block ensures that the instance is disposed once the block completes - otherwise you have to call DISPOSE on that instance yourself (remember if there is an exception you might not have captured this so you will at least have to manage this scenario.
Once you have an instance of of your domain context you can use it to search (in the case of Windows, the LDAP database) for users, whether by SID or unique name, in your case (every name must be unique - two users in the domain cannot have the same name).
The website has the security ID of the user, the code you are following gets a Domain object for that user which has the properties you will display. You could call other objects that might tell you which Windows Security Groups the user is a member off. In that way you can have a web site where a users ability to view a web page or click a button is down to which Groups in the Domain the user is a member of.
I have a Asp.net MVC application that uses Azure AD and OpenID Connect OWIN middlewares to handle authentication. Everything works fine except for one thing : if a user is already logged-in on another Microsoft Application lets say a Office 365 account or maybe a live mail account, when trying to login it recives a page saying that it is not allowed to log into my app, which is correct, but some how I need to catch that situation in my code to allow the user to sign in with a different account. Is there a way of doing that? This is by design? I mean : the user have to log in only with a live/azure account at the time ? I couldn't find any documentation about this.
As of today there is typically one user at a time, but we will soon support for you a way to select a specific user instead of automatically signing you in with the most recent one.
One way you can work around this today is by injecting the parameter "prompt=login" in your sign in requests. You can do that in the RedirectToIdentityProvider notifications, similarly to what is showin in http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/ for domain_hint. This will cause the sign in experience to always start with a fresh prompt even if the user is already signed in. The draw back is that you'll never get SSO this way. Hopefully our account switiching feature will become available soon, keep an eye on http://blogs.technet.com/b/ad/ for announcements
I have two applications in my workspace, APP 1 and APP 2.
In my case, user will log in to APP 1. from there, i put a menu(or a link) to APP 2. however APP 2 requires authentication. So it will take me to a login page. i would like to eliminate that and get the current user's credentials on APP 1 and login to APP 2.
i'm looking for a simple straightforward method (but need to consider security) to login to APP 2.
what i could think of is apex_collection..i could store credentials n use it to create a login process for APP 2. however apex_collection is session based. eventhough i've set session for APP 2, it still wont read values from my apex_collection.
Does anyone have a suggestion or a solution?
All you need to do is use the same authentication scheme in both applications and set the cookie name attribute to the same value in both authentication schemes like this:
APEX will then use the same session across the two applications and the user will not have to log in again when they navigate from one to the other, provided of course that you pass the SESSION_ID in the URL.
A Few Comments on Default APEX Workspace Authentication Security
It may also be helpful to expand on an explanation of why the solution posted by #TonyAndrews works.
For any Apex Apps within the same workspace, if they use the default "APEX Application Authentication" method, they will consult the same authentication user list... so USER1 and its password is a valid login for any of the "neighboring" applications...
This may be a concern if you are hosting different clients or users that should not be intermingling with the other applications. You can also define user GROUPS in the same place as you set up each workspace user. Each application can have its own security filter that permits access by membership of BOTH user/password authentication AND membership in the appropriate access group.
Sharing workspaces may also be a problem because of the unique user name restriction of a single workspace. You can get around that by:
Defining different name-spaces for each application:
Email addresses are good: "someuser#sampledomain.com"
An app id prefix such as: SHOP_EDNA, SHOP_GARRETT, TC_KAREN, TC_MARLOWE, MY_BORIS etc.
Different name styles: first name only, first name + last initial, etc.
To keep things simple, you can always just spin up a brand new workspace: a warning however is that common user names like `ADMIN` are NOT the same between separate workspaces. There shouldn't be much concern however because apps or workspace users may have the same or different schema access privileges to the database back end.
A Word of Caution to Administrators and Developers:
When you go live with an application or multiple applications on a user-facing system, keep in mind the deployment destination (i.e., the workspace) and what else is sharing that workspace. There are some real situations where apps are not intended to be shared or accessed by other "inside" users. Be sure to read up and understand the security constraints and methods of using Default Apex Authentication security so that it's more than luck that protects your own production/live deployed applications.
I do have the similar requirement, linking from one application page to another.
Tried the above mentioned solution, but still asking to login to second application. My Apex ver is 5.0.3 and trying in same workspace.
Created new authentication schemes for each app with same cookie name and set them as current authentication. Scheme type are Application express accounts.
Setting the link as below from first app page to second.
href="http://servername:port/apex/f?p=224:2:&APP_SESSION"
Could anyone provide a solution, please?
Just an update on this.
I am currently using v21.2 and this is how I do it:
In both applications, go to Shared Components > Authentication Schemes > (Select your Auth Scheme);
Scroll down to Session Sharing and select 'Workspace Sharing';
In one of the applications (source), create a link (as a Navigation Bar List entry, for example) like f?p=173:1:&SESSION., where 173 is the target application ID and 1 is the target page.
After some research, I've found out that this feature (Session Sharing Type) is available since v18 of APEX.
I have a problem on my silverlight application.
I login in my application using my ID (assume x) (using Internet explore 8),
so assume i can see some reports which is releated to my ID.
Without closing the above browser in another Internet explore 8 in the same machine i am login into the
same application using another ID(assume y), so now i can see 2nd set of reports which is related to this ID.
Now If i refresh the report page of the first browser which is got logged with the ID (x), I am seeing the (y)
userid's report not the earlier.
How to fix this?
Thanks
In internet explorer choose "New Session" from the "File" menu. This will create a new IExplore.exe process tree which manages its own set of session level cookies. This should allow you to maintain two separate logins at the same time.
Sounds like you are using the ASP membership provider... if so that is limited to 1 session per browser/user on the same PC (same limitation if it was a web app).
Why are you trying to login 2 different users from the same machine? If it is for testing you can probably open two different browsers (IE and FireFox?) and get two session that way.
Update (based on comments below):
Option A. As you need multiple user logins on the same machine in the same browser type, you cannot use the asp membership provider and will have to replace that provider with a Silverlight-specific credential/login system.
Option B. The alternative is to change your application to allow selection of client from within the app (this would be my choice as you are misusing users as a convenience).
Is it in any way possible to wire up an ACS rule to return/PassThrough the user's email adress from ACS using $(InputValue) when using Live ID?
I am using Passive authentication and get redirected out to Live ID but I was wondering if there is any way to wire up a rule from ACS that might get the InputValue email address
From what I can see I think this might be possible by hosting a login page of course but I would prefer to be able to get it in some other way from ACS if possible.
(I should have added that the current scenario is to implement Live ID authentication on top of an existing ASP.Net application with a database backend for user identity and roles.)
Extra information related to the current scenario : The current scenario is an EXISTING system with its own home-grown database authentication security model. I tried all sorts of ways to see if I could intercept the user's email address and eventually decided the available approaches for doing this were not desirable (in this specific scenario).
The only suitable and secure pattern found to transition to Live ID authentication in this scenarioo is to build a Registration system around your application which allows an existing user to register their LiveID and then bring them back to your application to capture their Live ID 'nameidentifier'.
However, given that any unknown user could do this it would be necessary to have an interim authentication step via email or some-such mechanism to validate the Live ID email address being used.
I hope this is of help to someone.
Possible but it requires a bit of code for a custom sts:
https://gist.github.com/1867792
Code doesn't build and dependencies aren't included... but it's largely based off an early thinktecture starter site ported to MVC4 with changes shown above.
Unfortunately it is not possible to get any identifiable claims when using ACS with Windows Live. This is due to Windows Live user privacy policy.
With windows live you will only get a ID claim which is unique to your Relying Party application.