This link describes how to retrieve the token for a specific managed identity, if a VM is configured with multiple identities.
What is the behavior if the identity is not specified in the request? For which identity is the token returned? Is it for the system identity, or for the first user identity, or for the first identity that was configured on the VM, or something random?
System assigned managed identity will be the default, if no identity is specified in the request.
If system assigned is not enabled, and only one user assigned exists, then IMDS will default to that single user assigned.
If system assigned is not enabled, and multiple user assigned exist, then specifying the identity in the request is required.
We'll update our docs to include this information. :)
Related
I am using JWT tokens as the authorization system. It works in the business layer with interceptor aspects.
Every time a request comes to my services, I check with this aspect whether the user is logged in or not. Also, I claim the user's claim roles with HttpContext.
When the user logs in, I add all the roles of the user in the token.
Roles contain access rights to services, each service method is a separate role.
Since the number of roles has increased, I get the following error when I send a request to my SignalR service.
When I delete the user's role number from the claim table manually, the error is fixed.
HTTP Error 404.15 - Not Found The request filtering module is
configured to make a request with a query string that is too long.
How can I increase the request filtering length?
When we store the Service principal certificate/appKey in the VM (to access the keyvault), we could limit access to that file to just the user account running the program. Other users or accounts wouldn't have access to the secrets in keyvault.
When we use Azure Managed Service Identity to access keyvault from an IaaS VM, my understanding is that any user logged into the VM or any program running on the machine can access the keyvault secrets - is this true?
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
According to the article access Azure Key Vault, it seems this is true. If MSI is enabled, just need to invoke web request in the VM without e.g. appKey.
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
It should be, but the prerequisites of the access to the secret in the keyvault is the VM service principal was added as a role in Access control (IAM) and Access policies.
If you want to increase the security, you may need to remove the VM service principal in the Access policies, then it will not be able to access the secret, if you want to the service principal does not have the access to the keyvault at all, remove its role in Access control (IAM).
For more details, you could refer to: Secure your key vault.
Update:
From the doc #Arturo mentioned, it is the fact.
Any code running on that VM, is able to call the managed identities for Azure resources endpoint and request tokens.
I'm writing a web application with spring boot and want that the user is able to tell me what his identity provider is. In a same way as I can do it on Stackoverflow.
How can I identify a user in a unique way? I already read that I should use the sub/Subject for distinguishing users. Is this unique when using multiple providers?
My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
How can I identify a user in a unique way? I already read that I should use the sub/Subject for distinguishing users. Is this unique when using multiple providers?
You'd store the combination of (iss, sub) as an identifier that is globally unique. As Kavindu mentioned already, the sub claim by itself is only locally unique.
My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
There are two ways of using "multiple providers" with your app, via:
a set of trusted IdP's
any IdP
If someone's real identity is important to you, then you can choose the providers you trust to provide someone's identity details. People then can only sign in via one of the providers in your list.
But if it doesn't matter that much (normal username/password registrations also don't provide any guarantees), then you could also choose to let people login with a provider of their choosing. The correct provider may then be discovered from the user's "handle" via OIDC Discovery.
Q : How can I identify a user in a unique way? Is this unique when using multiple providers?
According to OpenID Conenct specification, "sub" claim is locally unique. Following is the extraction from specification which highlight this (reference),
Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User
So when you are dealing with a single identity provider, "sub" claim is unique. But that does not hold for multiple providers.
Q : My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
I doubt about this scenario. Does your application allow end users to register different identity providers as they want ?
In OpenID Connect, there's a application registration step. Your application need a client identifier. Also registration process involve redirect URL registration. All these are done in registration step. Without these, OpenID Connect will not function.
Adding to that, different providers behave differently. For example, though "sub" is the standard claim to communicate end user identity, a provider may use a custom claim to define a specific user identity. This is allowed by OpenID Connect specification. So your application must only support known, well established identity providers which you know at the application design time.
This is a similar question to many that I have seen before but I have not found a clear answer yet so I will try to be very specific here to avoid duplication.
We are running IIS7.5 on 2008R2 with only windows authentication turned on (no anonymous) and no impersonation. There is a network account specified for the application pool user.
When I check the WindowsIdentity.GetCurrent() of the currently executing page I get the expected (App-pool) user based on our configuration.
http://www.mikeobrien.net/blog/identities-for-different-iis7/
This matches the expectations nicely. However, it appears that NTFS folder permissions on our application are being checked against the identity of the authenticated user.
This seems to contradict most of the documentation I have found. The above link as well as
http://msdn.microsoft.com/en-us/library/kwzs111e(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/3yfs7yc7(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
How is IIS checking the authenticated user's identity in folder ACLs when .Net is clearly indicating that the WindowsIdentity in play is that of the App-Pool?
The only theory I have so far is that the file authorization module is utilized with integrated authentication automatically and it is explicitly checking this... but it still seems to go against the documented expectation.
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
This article, for example, seems to document both expectations.
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser. Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request.
Followed a few lines later by
Windows authentication without impersonation. This is the default setting. ASP.NET performs operations and accesses resources by using your application's process identity, which by default is the application pool identity on Windows 7 and Windows 2008 R2. For more information, see Application Pool Identities.
Windows authentication with impersonation. With this approach, the Web application impersonates the authenticated user and uses that identity to perform operations and access local resources. When you configure your application for impersonation, an impersonation token for the authenticated user is attached to the Web request thread. As a result, all local resource access is performed using the caller's identity.
My question:
What identity should be used when file system ACL checks are performed? (My understanding was App-Pool when impersonation = off) and what settings might affect which identity is used outside of impersonation?
This is very similar to this question:
Does an IIS 7.5 web app with windows authentication require end users to have file permissions?
The marked answer on this question does not address my concern. Authorizing 'authenticated users' group should not be required as the identity being used should not rely on the set of end-users being authorized. My question is much more specifically, which identity and how is this controlled?
"NEW IN IIS 7.5
IIS 7.5 added the authenticatedUserOverride attribute to the element, which configures whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity in the IHttpUser::GetPrimaryToken and IHttpUser::GetImpersonationToken methods. This attribute can be set to UseAuthenticatedUser or UseWorkerProcessUser, and these values respectively specify whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity for any module that is using impersonation."
Source
We are building a set of web applications which all utilize their own unique role providers using sql server and utilizing Windows Identity Foundation to provide a Secure Token service to handle the membership using Active Directory. This solution also provides the benefit of single sign on. One oversight was only allowing users a single session. Tracking if the user already has an active session seems easy enough to implement, it’s what and how to deal with a user’s session if it’s determined they are already logged on elsewhere .
My question is what is the recommended approach for killing an existing user session if the user attempts to spawn an additional session? Would also like to advise the user that an existing session has been detected and by continuing, that existing session will be terminated. (This part also seems trivial…)
Example Scenario with 2 web apps and a STS Identity app:
User attempts to access application A:
STS Identity extension determines user is not already logged on, provides a claim and caches a user/session identifier.
User attempts to access application B on different computer. (they can access application B if using the same session)
STS Identity determines user has active session and denies logon.
There seem to be some other issuer to overcome, for example….
How to update the logged on user cache from the application A if the user is actively keeping their session alive.
How would you deal with the user not explicitly logging off, say by closing the browser or the session timing out.
Other problems???
Any guidance would be appreciated.
We have opted to handle concurrency at the application level, using a simple table that stores the users session id. If a new session for the application is created elsewhere, the existing session is terminated with the use being redirected back to the STS with a message (carried in the query string) the reason why they've been redirected back to the login page.