I have an ASP.NET MVC 4 application that is using CSLA.NET for a portion of our business logic. The permissions to read/write are handled through AD by a domain account, the same account as the Application Pool Identity and .NET Impersonation user. When testing on my local machine, the validation runs perfectly. Once the application is deployed to one of our test environments (dev or qa) I receive exceptions that seem to point to permissions. I've verified that the username being used by the assembly is indeed the correct user, but have been unable to set the values of any of the fields due to not having the appropriate permissions.
Anyone experienced anything like this before?
EDIT:
Link to discussion on lhotka.net forums
Web servers are stateless, so they don't generally remember anything between page or service requests. This includes the user's identity and roles.
If you are using ASP.NET forms security (or similar) the username will be automatically recreated on the server by using the .NET authn cookie token, but that's only the username.
You are responsible for recreating the complete principal/identity object on the server for each postback/request.
The easiest way to do this is in the global.asax file, often in the authenticate request event. There are samples in the CSLA download showing how to do this, and I discuss it in the 'Using CSLA 4' ebook series.
Also any good ASP.NET book will discuss restoring the principal, because this isn't really a CSLA issue as much as a web development issue.
Related
What is the recommended approach for user management with IdentityServer4 and Active Directory?
I have started with the IdentityServer4 ASP.NET Core interactive quick start and all is working well. However, the sample code uses the TestUserStore, TestUserProfileService etc., and it seems prudent to replace usage of these.
The 'real-world' alternative seems to be using ASP.NET Core Identity, however this persists user details to the IdentityServer database. Given that IdentityServer isn't the source of truth for this data, this is an odd fit.
Apart from the "test" nature of the quick start classes, these are serving our needs well. Our IdentityServer instance is for internal staff in a small organisation, so the in-memory nature of these stores isn't a problem.
This seems to be a fairly common use-case, so I must be missing something. Can one just delegate all user profile calls to Active Directory? Is there any out of the box code for this?
Identity Server is an implementation of OAuth 2.0 and OpenIDConnect(Built upon OAuth2.0). The key point of OAuth 2.0 is to pretect resource such as WebApi based on Access Token. So what does OAuth 2.0 provided is Authorization.
Identity Server can provide Authenticate service provided by ASP.NET Core Identity, as specified in This Document
In your case, you'd like to delegate the authenticate part to AD, and authorization part to Identity Server. You can refer to This document to enable windows authenticate in your asp.net core application
I resolved this by implementing and registering an IProfileService for Active Directory. It still seems oddly hand-rolled, but seems to do the trick.
I have been scratching my head for a while now. Went through tons of documentations but everything seems very confusing. Please forgive if it appears to be a duplicate question, but believe me, the more content I find, the more its confusing me.
Below is the configuration of my project and what I need to achieve:
The project is a web based application developed using Spring framework with Java 8 that is hosted on S3(linux server). HTTP server used is Apache. JBoss is used as an application server and the exact version used is wildfly-8.2.0.Final.
Currently, the user enters his credentials which are validated against Microsoft Active directory using LDAP and is let in. The requirement now is that when the user logs into the machine using his AD credentials in his intranet environment, and he tries to open the application, he should directly log in and not prompted for credentials again. If he is outside his intranet network, the existing log in method should be followed.
While researching I found the below things I assume can be useful but not able to reach to a conclusion.
Kerberos along with Shibolleth: I went through below two references which somewhat matched with my requirement but not very sure am I looking at the right thing or not.
http://richardjohnson798.blogspot.in/2011/10/single-sign-on.html
http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf
My confusion revolves around the below things.
Is Shibolleth the right choice. If yes, what is the exact role of Shibboleth?
What things needs to be setup on the linux server(Kerberos implementation for example), and what changes would be needed in the client's AD environment?
Is the implementation possible on the Wildfly server? (as all the references have the thing implemented using Tomcat).
What are the security aspects I should be concerned about.
Help is much appreciated. Thank you.
Since you are using S3 I assume you are using AWS.
Go to IAM and add the Active Directory as a SAML provider
https://aws.amazon.com/blogs/mobile/announcing-saml-support-for-amazon-cognito/
Then use AWS Cognito Federated Identity Pool via the JavaScript SDK in the front end code you have hosted on S3.
http://docs.aws.amazon.com/cognito/latest/developerguide/using-amazon-cognito-user-identity-pools-javascript-examples.html
I'm building a Web Application using ASP.Net and MVC4. This web application is going to be used by another company but we are hosting it. We were told that we had to use ADFS. We don't know what kind of information is going to come over to us in the authentication but we need to allow for users to have roles. I assume that when authenticated a username should be returned. So i'm thinking I would build a user table in the database for admins and super admins. When a user comes over, we will check if there username exist in the database and if so we would read their role from the database If they do not exist in the database they are public.
All that being said here is my dilemma that I need to solve. How do I do this without writing custom code everywhere in the application to check for authorized and check for role? I would like to use the [AuthorizeAttribute(roles)]. Should I create a custom role provider? All ideas are welcome. BTW, we can not have the client manage the roles and pass it over because this company is a Fortune 100 company and they do not have time to handle these request.
I would recommend looking at some of Dominick Baier's work on securing MVC with claims. He's worked with some other developer's as well to build Thinktecture, which has both an Identity Server component and libraries for assisting in the processing of claims while abstracting some of the nitty-gritty details.
As for the roles portion of what you need to do, you can build a custom ClaimsAuthenticationManager and have that perform whatever transformations or additions to the users claim set at initial login. Dominick has a couple of excellent PluralSight courses that go into much more detail on this process. He also has this free video out there, which details the authorization portion around minute ~44.
I recently went through the effort of getting ADFS setup and authenticating some of the MVC apps at our company. The resources I have referenced were invaluable in helping me in that process.
I'm working on a WCF project that will be our new service layer.
These services will be called by 2 separate clients, the first of which is a WPF application and the other is an ASP.Net web application. The WPF client will be run by internal users and will authenticate with the service via domain authentication and run under the context of that user. The other will be used by external users and needs to authenticate using some separate mechanism then impersonate a "WebUser" account on our domain.
I'm reading a bit about Windows Identity Foundation and it sounds like this might be a good fit. Am I right in thinking I could have 2 token services, one for domain authentication and one for something like ASP.Net membership authentication (Or some similar equivalent) and have each client get it's token from the relevant STS and pass that along to the WCF service?
I'm assuming there is an STS I can use out of the box for domain authentication, but will I have to implement the second one myself to authenticate web users? I can't find a lot of information on this.
Am I thinking along the right lines or should I just be creating duel endpoints for each service each with a different authentication mechanism? Or should I be doing something completely different?
Thanks
The big advantage of using Claims-Based authentication / WIF is that both the task of authenticating the user AND the administration of the user's properties are moved way from the applications to the STS/Identity provider.
You are developing a service layer but the true benefits of using WIF will be for the applications written on top of your layer. The WPF application will no longer need to connect to the AD and fetch the user's groups to figure out what they are allowed to do. The groups will already be visible as claims in the token the user/WIF provides.
The web application (is it just one web application or more?) will no longer need the ASP.Net Membership database with accompanying user administration. This functionality gets moved to the STS.
There is a cost. (There always is, somehow...) Claims-Based authentication has a rather steep learning curve. It takes a while for the quarter to drop for all people involved.
So the answer to your question depends on what kind of users the web application(s?) built upon your service layer have and how many. And how much they wish to know about them. Can you perhaps trust Google / Facebook / Windows Live for authentication? Are the users already in an existing database within your domain? How much work will it take to maintain the user directories? Do your marketing people wish to send them emails regularly? Et cetera.
This is probably not just for the service layer's developers to decide, but something to discuss with people in the rest of your organisation.
If the benefits are not particularly big, the alternative is to simply keep these responsibilities at the web application's server. Each web application will have a good old ASP.Net membership database, it'll authenticate the user all by itself. When asking queries from the service layer, it'll present its web server certificate plus specify the user's name and type.
If the benefits are big enough, you can in principle use ADFS 2.0 for everything. It can also store external users nowadays and it's free if you already have Active Directory. Or the ThinkTecture 2.0 server that Ross recommends. It's easier to customize and perhaps your systems administrators and security folks will not be too enthusiastic about opening the firewall to the ADFS server.
Microsoft has some good reads on WIF, in particular an Overview of Claims-Based Architecture.
You should take a look at identity server as it can indeed handle this scenario.
The person who leads the project above has a great pluralsight video on this exact scenario! You need to sign up to watch it, but they offer a free trial.
Basically you get a token from the identity provider (windows ADFS for the internal client, and what ever you decide for the external users). You will give this token to the federated gateway (identity server probably, but it could be Azure ACS). This will return an authentication token that you can then use with your service.
I need to create a wcf service which would be consume by silverlight apps downloaded through internet. Basically the users are not part of any windows domain but there credentials and roles are maintained in database.
The wcf service should be internet enabled, but methods cannot be accessed anonymously.
Authorization should also be supported\
User and roles tables are not as per ASP.NET membership schema
Developers should not be constrained to have IIS installed and certificate configured
Authorized users should be able to access only his related information. He should be able to delete or update his related companies but not others.
To achieve 1 & 2, i had followed below link.
WCF security by Robbin Cremers
To cover point 3, i have provided custom implementation of MembershipProvider and RoleProvider classes and overridden methods ValidateUser and IsUserInRole respectively to fetch from my own schema user and roles table.
So far, so good authentication and authorization works fine.
Now the problem, the developers can't have IIS installed and certificates configured, so need to disable this in development mode. Hence have implemented custom CodeAccessSecurityAttribute class which would check development mode or production and use custom IPermission or PrincipalPermission.
[Question 1]My question is I don't anywhere people recommend this approach, so litte afraid whether this is the right approach or any better approach is there to handle this situation.
[Question 2] Lastly related to point 5, do i need to send some kind of token over? What is the best approach for this?
[Question 3] Performance impact in Robbin Cremers method, since for every service call, two extra database calls will be made in "ValidateUser" and "IsUserInRole" to authenticate and authorize. Is there a better way?
Sorry for the big question.
As far as I can tell from your scenario description, once you've created and hooked up your custom Membership / Role providers, you don't really need Message Security. Instead, the standard approach described in http://msdn.microsoft.com/en-us/library/dd560702(v=vs.95).aspx will work just fine (or http://msdn.microsoft.com/en-us/library/dd560704(v=vs.95).aspx if you want users to log in via your Silverlight app instead of via a regular web page). The browser then handles the sending of any required tokens automatically (via cookies), and I'm guessing ASP.NET is smart about caching authentication/authorization results so the overhead should not be incurred on every call.