Multiple applications using same login database logging each other out - asp.net

I've set up two ASP.NET applications on a machine, their web.config files contain the same applicationName value in AspNetSqlMembershipProvider item so they share users and roles.
The problem sequence is:
user logs into application A,
opens new tab in a browser
logs into application B,
his login in application A is signed out
and vice versa.
Should I use a different approach to sharing login information between two applications?

The problem you have is because the same cookie used, for authenticate the 2 different logins.
The solution from what I understand is to give different cookie name on the different logins, so the one cookie, not overwrite the other one.
Probably the solution is on web.config.
On Config
Change the name value, to something different on your 2 apps, if you have the same domain and run on different directory/apps, or change also the domain value that used also to keep the cookie.
<authentication mode="Forms">
<forms name=".CookieSuffix" domain="yoururl.com" ... />
</authentication>
For example, on the 2 diferent web.config on your apps, place
on app 1: name=".app1"
on app 2: name=".app2"
Or
on app 1: domain="app1.yoururl.com"
on app 2: domain="app2.yoururl.com"
if you separate your apps, base on url, or even try some similar aproces.
The cookie is keep, using the cookie name on the domain name, so this is the 2 values that you must try to seperate them.
Details on Form setup can be found here:
http://msdn.microsoft.com/en-us/library/aa480476.aspx
Manual login
If you have the oportunity to make manual login the solution is on this function
FormsAuthentication.GetAuthCookie(cUserName, false, "cookiePath");
FormsAuthentication.SetAuthCookie(cUserName, false, "cookiePath");
You only need to use a diferent cookiePath, but, you must change many points on your program, and capture the process login, logout and Authenticate.
Hope this help you.

You should check out this tutorial.
Scroll down to the section titled Partitioning the User Store Into Applications. It says there that you can use the same user store for multiple applications.

Related

Azure AD B2C: How to differentiate the serviceUrl of a called REST API based on a value from the consuming app

I am investigating the possibilities of Azure AD B2C. I have the following use case:
I have a Xamarin Forms app. In the current app, a user can choose three different environments (A, B, C) when logging in. Each environment has a separate - but similar - website, think of it as staging environments. So the choice of environment dictates in which website where the actual login takes place. A user should be able to logout of A and then login again in B, for example.
Now I want Azure AD B2C handle the authentication instead. I set up a tenant and create a custom policy to make a rest call to the website to do extra validation steps with the objectid in the last orchestration step. This mechanism is working fine.
The problem is that the REST calls to the serviceurl is slightly different for environments A, B of C.
In the orchestration I guess it should be possible to make the three separate REST steps and make them conditional on some parameter. The question is which parameter. A custom claim?
The Xamarin app uses msal to connect to the tenant.
What mechanism can I use from the app to know in the custom policy that a login is for environment A, B of C?
Can it be some parameter?
Or should I make three different Application definitions in B2C, and use the ApplicationId to differentiate?
Following Jas's comment, I added WithExtraQueryParameters to the app:
await App.AuthenticationClient
.AcquireTokenInteractive(scopes: Constants.Scopes)
.WithExtraQueryParameters(new Dictionary<string, string> { { "website_code", "TEST" } })
.WithPrompt(Prompt.ForceLogin)
.WithParentActivityOrWindow(App.UIParent)
.ExecuteAsync();
Some key snippets from TrustframeworkExtensions.xml:
<ClaimType Id="website_code">
<DisplayName>Website code</DisplayName>
<DataType>string</DataType>
<UserHelpText>The Website code</UserHelpText>
</ClaimType>
<InputClaim ClaimTypeReferenceId="website_code" DefaultValue="{OAUTH-KV:website_code}" AlwaysUseDefaultValue="true" />
<OrchestrationStep Order="7" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="false">
<Value>website_code</Value>
<Value>TEST</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="RESTGetUserClaims_test" TechnicalProfileReferenceId="xxxx_test" />
</ClaimsExchanges>
</OrchestrationStep>

Virtual Directory Physical Path Credentials for Specific User Getting Bad Data Error as This Portal No Longer Window Authentication

I have this portal that contains applications that range from classic asp to asp.net 4x. The transition from WIA to Forms Authentication has been accomplished manually as this delicate monstrosity will not accept any other way. I have only one hurdle left and this is accessing the virtual directory that stores images and documents for one of the apps and which no longer have the physical path credentials supplied by window authentication.
There is no application to control this virtual directory and I need to transition from Application user(pass-through authentication) to Specific user in IIS 7.0
I have tried to Set Credentials for a generic user and my own admin account but get the Bad Data error 0x80090005 which generally tells me there is no encrypted credentials in applicationHost.config
I assume that the logon type is clear text and these keys should be in the applicationHost.config.
Any hints at how to create these keys would be appreciated.
I ran the command that Lex Li pointed me to:
appcmd set vdir /vdir.name:"ExampleSite/ExamplePathDir" /userName:"username" /password:"XXXXXXXX"
And received the Bad Data error:
ERROR ( hresult:80090005, message:Failed to commit configuration changes.
Bad Data.

Configure authentication and synchronization with two LDAP in Alfresco 5.1

We perform migration from enterprise version Alfresco 4.2 to the 5.1.
There are two Active Directory domains (primary and child) in company, for this reason we configure two LDAP(AD) subsystems in Alfresco 5.1.
Structure of properties:
/opt/tomcat7/shared/classes/alfresco/extension/subsystems/Authentication/ldap-ad/ldap2
/opt/tomcat7/shared/classes/alfresco/extension/subsystems/Authentication/ldap-ad/ldap1
Problem is that authentication and synchronistaion work only for one ldap-ad subsystem (ldap1 or ldap2), which have first place in the list of authentication chain (ldap1 and ldap2 don't work together).
Authentication chain screenshot
For a example, if ldap1 have first place in the list, that user's login from ldap2 fails (and conversely!).
In this case I look error in alfresco.log:
Caused by: net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid SecureContext was not provided in the RequestContext
My properties:
/opt/tomcat7/shared/classes/alfresco/extension/subsystems/Authentication/ldap-ad/ldap1/ldap-ad-authentication.properties
ldap.authentication.active=true
ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=%s#fake.local
ldap.authentication.java.naming.provider.url=ldap://fake.local:***
ldap.authentication.defaultAdministratorUserNames=fake_user
ldap.authentication.java.naming.referral=follow
ldap.synchronization.java.naming.security.principal=fake_user#fake.local
ldap.synchronization.java.naming.security.credentials=somepassword
ldap.synchronization.groupSearchBase=ou=Archiv,ou=FileServerGroups,ou=Groups,dc=fake,dc=local
ldap.synchronization.userSearchBase=dc=fake,dc=local
ldap.synchronization.groupDisplayNameAttributeName=description
ldap.synchronization.userOrganizationalIdAttributeNameCustom=distinguishedName
ldap.synchronization.com.sun.jndi.ldap.connect.pool=true
/opt/tomcat7/shared/classes/alfresco/extension/subsystems/Authentication/ldap-ad/ldap2/ldap-ad-authentication.properties
ldap.authentication.active=true
ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=%s#gss.fake.local
ldap.authentication.java.naming.provider.url=ldap://gss.fake.local:***
ldap.authentication.defaultAdministratorUserNames=fake_user
ldap.authentication.java.naming.referral=follow
ldap.synchronization.java.naming.security.principal=fake_user#fake.local
ldap.synchronization.java.naming.security.credentials=somepassword%
ldap.synchronization.groupSearchBase=ou=Archiv,ou=FileServerGroups,ou=Groups,dc=gss,dc=fake,dc=local
ldap.synchronization.userSearchBase=dc=gss,dc=fake,dc=local
ldap.synchronization.groupDisplayNameAttributeName=description
ldap.synchronization.userOrganizationalIdAttributeNameCustom=distinguishedName
ldap.synchronization.com.sun.jndi.ldap.connect.pool=true
alfresco-global.properties
### Authentication ###
#authentication.chain=ldap1:ldap-ad,ldap2:ldap-ad,alfrescoNtlm1:alfrescoNtlm
authentication.chain=alfinst:alfrescoNtlm,ldap1:ldap-ad,ldap2:ldap-ad
Thanks in advance!
Finally, I resolved issue related to authentication users.
I put empty string of parametr:
ldap.authentication.userNameFormat=
for each LDAP subsystems in files ldap-ad-authentication.properties.
After, users from two ldaps could login successfully.
ldap.authentication.userNameFormat
Specifies how to map the user identifier entered by the user to that
passed through to LDAP. If set to an empty string (the default for the
ldap subsystem), an LDAP query involving
ldap.synchronization.personQuery and
ldap.synchronization.userIdAttributeName will be performed to resolve
the DN from the user ID dynamically. This allows directories to be
structured and does not require the user ID to appear in the DN.
If set to a non-empty value, the substring %s in this value will be
replaced with the entered user ID to produce the ID passed to LDAP.
This restricts LDAP user names to a fixed format. The recommended
format of this value depends on your LDAP server.

Login failed for user 'domain\ServerName'

I have creates an asp.net mvc 4 web app. I have deployed it to my dev server. (different box than my local on same domain).
Both the database and the website exists on the same server/box. I am trying to connect from my local machine which is on the same domain as the server.
I try to login on the home page and I get this error:
Login failed for user 'domain\ServerName'
I don't know where this is coming from or how to resolve it. I assume it has something to do with IIS. Any help would be appreciated.
I had this problem - It was my connection string. Somehow, it now magically now had both ;User ID={login value here};Password={password value here} and Trusted_Connection=True; key/value pairs.
You cannot use both. If you have a SQL Server login, then you don't want the Trusted_Connection=True;. If you have a trust between machines, then you don't want the ;User ID={login value here};Password={password value here} values.
It makes sense that this applies to Integrated Security=SSPI; and Integrated Security=true; too. You must leave off User ID and password when you use those as well.
(6 years late, but maybe it'll help someone else)

ADFS Skip Home Realm Discovery using integrated auth

My scenario:
I've got a .net web application where people log into the app with forms authentication, and my forms authentication code sends certain users off to ADFS to be verified. I have multiple federations, including my own Active Directory server for internal users. So, for users that need to be sent to ADFS for authentication, I do something like this:
WSFederationAuthenticationModule instance = FederatedAuthentication.WSFederationAuthenticationModule;
SignInRequestMessage request = instance.CreateSignInRequest(Guid.NewGuid().ToString(), instance.Realm, true);
request.AuthenticationType = "urn:federation:authentication:windows";
//maybe you just don't need to specify the homerealm for ad, because there can only be one AD (integrated) trust?
//request.HomeRealm = "I-no-idea-what-to-put-here-for-AD";
Response.Redirect(request.WriteQueryString());
When you do this, you set the .HomeRealm property which populates the whr attribute for you on the query string. This should make AD FS skip the HRD (Home Realm Discovery) page. For most of my federations (remote STSs) it's very clear what value I need to put in the property, you can pull the value from the dropdown box on the HRD page itself, or you can go into the AD FS management tool and pull the value from the trust properties. For the AD trust, however, there is no value in the dropdown list (empty string), and you can't go to properties in the management console. So the question is really this: if I want to preselect the AD trust through the whr parameter, what do I set the HomeRealm Property to?
P.S. you'll see the comment there: "maybe you just don't need to specify the homerealm for ad, because there can only be one AD (integrated) trust?" I think this might be the case, but I haven't proved it yet. I will answer this later if my guess is correct.
From the code in the original question:
request.AuthenticationType = "urn:federation:authentication:windows";
That particular line didn't appear to have any effect. Also, the hope that no HomeRealm need be specified was also in vain. It turns out that you must, in fact, specify the HomeRealm. After searching google for some time, I found many statements hinting that the Active Directory trust was the same as trusting the ADFS server itself. So as a wild shot in the dark I tried putting in the URI of the ADFS server, and, much to my pleasure and surprise, this worked.
So, to be more clear, if you go to the web.config of the relying party you should have something set up similar to this:
<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
<authority name="http://testadfs.test.com/adfs/services/trust">
<keys>
<add thumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" />
</keys>
<validIssuers>
<add name="http://testadfs.test.com/adfs/services/trust" />
</validIssuers>
</authority>
</issuerNameRegistry>
I ended up setting the value of request.HomeRealm to the value that you see there in the validIssuers and authority elements. This gave me the desired effect of causing ADFS to automatically select the Active Directory claims provider trust.
I should be clear that my ADFS server is NOT the domain controller, and yet this still works.

Resources