I work for a department of a university that uses CAS to provide single-sign-on authentication, and am writing a CakePHP application that needs to use this CAS service. I need to write code that:
Checks with the CAS server to see if the user is logged in
Pulls some credentials from the server if so
Checks the credentials against an internal ACL, as the set of people who can access the application is a subset of the set that can log into the CAS service.
Provides some mechanism for admin users, either by creating special admin users outside the CAS system (with all the headaches that would entail) or by promoting certain CAS users (with the different headaches that would entail).
As a relative newcomer to CakePHP, I frequently struggle with where to stick code that "doesn't belong". The best I can figure is that this code ought to go in the beforeFilter method of the App Controller, but I wonder, is this the best place for it? Also, is it too low in the stack to take advantage of admin routing?
Lastly, I know that CakePHP provides both Auth and ACL components, but when I looked into using them they did not appear amenable to interfacing with outside authentication services. Am I wrong, and would either of these be a good fit for what I need to do?
Thanks!
If you take a look at the Cake's core components you can see that your CAS requirement fits with the type of things components are typically used for (ie. auth/session).
I would recommend creating a CasAuthComponent. There is some information on extending AuthComponent, in a previous answer of mine, which may prove useful if you wish to build on top of the existing core AuthComponent.
A component (essentially reusable controller code) can interact with models, use other components (such as Session) and control user flow (redirects for example)
Note that, the core AuthComponent actually retrieves information from a model (the User model by default), so you could do something similar.
The CasAuthComponent you create could $use an external user model (CasUser maybe) which is responsible for CRUD operations on the data (retrieving users mainly).
You could take this one step further and abstract CAS interactions into a datasource used by this model, but it isn't strictly neccessary if you don't plan on reusing the code in other models.
The end result could be packaged into a plugin:
CasAuthComponent (app/plugins/cas/controllers/components/cas_auth.php)
CasUser (app/plugins/cas/models/cas_user.php)
CasSource (app/plugins/cas/models/datasources/cas_source.php) [optional]
And used in your application by putting the following in your app_controller:
public $components = array('Cas.CasAuthComponent');
If you wish to be able to administer the users from Cake, you can also include a controller and views in your plugin, which allow the user to interact with the CasUser model (ie. $this->CasUser->save()).
Related
I am currently developing a codebase for all mobile projects developed by our team.
One of the main services I'm working on is the authentication service, but I am unsure about whether to treat authentication and the user together or separated, understanding authentication as all the process of obtaining and storing the authentication token (sign in, sign up and sign out), and user as the instance of that user, all its data and all the methods linked to it (CRUD of the user and related content).
You really want to think about authentication and authorization separately if you can. For small enough project's it's worth consolidating, but the more separation you can include the better for the future.
Just to baseline:
Authentication => Who are you?
Authorization => What can you do?
Authentication paradigms are almost always (these days) external, from SAML, to FIDO2, to whatever comes next... It's going to be a moving target, and you DON'T want your authorization scheme tightly tied to it. Authorization is almost always an internal concern, and should not be tied to the flavor of the week that is authentication. Not to mention the fact that it is a near certainty that you will soon be supporting multiple authentication protocols simultaneously (you aren't already?), and embedding roles based on that auth is a messy thing at best.
Also, you are at some point going to need to do something horrible, like dumping your user database and moving to a new provider. Don't make that even messier by putting all your authorization logic in there.
Finally, testing is immensely easier when you can mock authorization without authentication. Test cases will dramatically simplify if you can "impersonate" a different role on demand.
In any reasonably large/complex product you will have multiple domain views onto a user.
Each of these views will translate into separately stored data and logic/services for each view. The key being separation of concerns.
In order to make sure the different views can be connected it is useful to have a common identifier for a user that you may want to pass between services. But you may not need to pass a lot of additional information across the services. For example the domain services do not need to know about passwords etc.
Even in your question an authentication service may be separate from an authorization service may be separate from anything else, etc.
JHipster implements several best practices for authentication and authorization.
Mainly described here: https://www.jhipster.tech/security/.
But I still do not see an example how to design a solution, which does not involve putting user verification logic all over the place for a very common use case.
Let's say you have a WebPage using REST-API like BankAccountResource from JHipster Sample App and you want to restrict this to only ADMIN role or currently logged in User. Let's say you have 50 of such services for your customers: BankAccount, Address, BillingAddress, UserData, Devices... For every resource a GET and UPDATE must be restricted. Also loading device /api/device/{id} might not include user-id.
How do I prevent UserA from loading UserB's device by guessing it's id?
How do I avoid planting that code in every method?
I guess JHipster/SpringSecurity has concept/objects to handle such use cases. Could you point me, explain how to use them please?
Maybe this question helps a little bit: Restrict URL access control by id in jhipster
Spring Security hast PostFilters to check if an object e.g. loaded by a method may be accessed. If you need more control you can use Access Control Lists for fine grained access control.
References:
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#domain-acls
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#method-security-expressions
I have a very complex requirements to implement the roles and permissions in my asp.net mvc 4 application. I know about ASP.NET Identity authentication but that does not fit into my requirements.
I have 15-20 controllers in my applications which have their respective views, some of views have partial views which are being handled in Jquery code and loaded from there.
Now I have below requirements:
1)Some of controller are accessible to a perticular role(s) only.
1) Some of views in a controller are accessible to a perticular role(s) only.
2) In a view for a Grids only some of columns and actions like Edit/Create/Delete are accessible to a perticular role(s) only.
I am thinking to implement checks on controller , actions and views on the basis of role but that can lead into a problem when I have multiple roles and custom roles in future. What can be best way to implement this kind of solutions. Any suggestions will be appreciated.
Every time you have "complex" authorization requirements, it's a pretty good indication that "identity-centric" access control is not enough. What's identity-centric? Authorization that relies on user metrics (identity, role, group) only.
Also, in your question, you list the fact that you do not know what the future holds. You do not know what other custom roles you need to implement.
All this means you need to extend your existing RBAC implementation with attribute-based access control (abac). ABAC gives you 3 interesting elements which you do not have in RBAC:
A policy language. You can express complex authorization challenges using this policy language (either of xacml or alfa). In particular you can express things like Permit if user department==record department.
An architecture: the architecture identifies key components with specific responsibilities. For instance, you have a Policy Decision Point (PDP) which produces authorization decisions. You have a Policy Enforcement Point (PEP) which is the piece that sits in front of or inside your application. The PEP protects the application.
a Request / Response scheme between the PEP and the PDP. The standard format is a Yes/No question as shown in the diagram below. JSON can be used to encode the requests.
From your point of view, you have two options. Either:
Implement claims-based authorization. This is available OOTB in .NET
Bring in XACML. I'm not sure .NET has any native libraries but there are SDKs out there.
I'm looking into crafting an app with DDD+CQRS+EventSourcing, and I have some trouble figuring out how to do user auth.
Users are intrinsically part of my domain, as they are responsible for clients. I'm using ASP.NET MVC 4, and I was looking to just use the SimpleMembership. Since logging in and authorising users is a synchronous operation, how is this tackled in an eventually consistent architecture?
Will I have to roll my own auth system where I keep denormalized auth tables on the read side? How to handle the security of this? Will I end up storing password hashes in both my event store and my view tables?
So many questions, if anyone can shed some light, I would be very thankful :)
tldr; How do you do User Auth in EventSource-applications?
Not every "Domain" or business component has to use DDD or CQRS. In most cases, user information is really cruddy, so you can usually not use DDD for that. Other domains don't really depend on the actual user. There's usually a correlation id (UserId) that gets shared by the various domains.
If using messaging in your system, one option is to register and manage users without CQRS, then send a command (RegisterUser { UserId } ). This would publish an event User Registered. Other domains can listen to this event to kick-off any workflows or ARs that are needed.
For our MVC CQRS app, we originally started off keeping all the user related information in the domain, and, like somebody mentioned, there was a RegisterUserCommand and a UserRegisteredEvent. After storing the user information in the domain, that event got published and picked up on the read side, which also created a user and generated all the password hashes, etc. We then done the authentication on the read side: the controller would make a call out to a 'read model authentication service' to authenticate against.
Later on down the road, we ended up completely refactoring this. It turned out that we needed access to the user related information to build in security for authorising our commands, which we done on the command processing side (our app is a distributed app that sends 'fire and forget' asynchronous commands to a queue, with an autonomous listener on the other side). The security component then needed a reference to our domain to go and get the user profile, which led to cumbersome referencing issues.
We decided to put the user security stuff into a separate database that we considered to be more of a central component, rather than belonging to the domain or read model. We still maintain user profile related information in the domain and read models (e.g. job title, twitter account URL etc.), but all the security related stuff, like password hashes, are stored in this central database. That's then accessible with a service, that's available to both MVC and the command authoriser.
We didn't actually have to change anything in the UI for this refactor, as we just called the service to register the users from the register user command handler. If you're going to do it that way, you need to be careful here to make your user service related operations idempotent. This is so that you can give your commands the opportunity to be retried without side effects, because you're updating 2 sources of information (the ES and the user database).
Finally, you could of course use the membership providers for this central component, but there can be pitfalls with that. We ended up just writing our own - it's pretty simple to do. That article links to this, which provides a good example of how to implement it.
You should consider creating separate entities like: visitor (just visited your site), user (registered), customer (bought something), etc. Try to split your system in this way, even if it causes a little bit of data redundancy. Disk space is not an issue but ability to modify different components of the system independently is usually very critical.
People create denormalized auth tables only for the purpose of scaling and only if your auth read side is a performance bottleneck. If not - usual 3rd normal form is a way to go.
In SimpleMembership scenario all tables created by SimpleMembership can be viewed as snapshot of "user" aggregate. And yes, they will duplicate some data in your event store.
You may have events like: UserCreated, UserUpdated, UserAssignedToRole, etc.
And don't be tricked by the name of that membership provider. It's not so simple and usually has lots of things that you can easily live without (depends on your domain). So, maybe you can use something like this: https://gist.github.com/Kayli/fe73769f19fdff40c3a7
How to set password (the best if it was in database, so Entity with one record) on some pages (create/edit/delete view and controllers)? It can be redirect to entrance page with form with password field.
I would also recommended you to go with 'spring security core' plugin.
By using spring security core you will be able to :
(1) secure all of your project's possible URLs
(2) provide access to required pages to particular role
(3) assign one or more then one role to particular user
(4) manage individual users with basic information as well as storing password into encrypted form etc.
(5) Its in-built reach set of tag library will help you alot to reduce the logical code.
Apart from the above, the major advantage of using spring security core would be its simplicity and extensibility. As its advance features like :
LDAP
ACL
OpenID
CAS etc
are available with different plugins.
Also there is one more plugin called 'spring security ui' is available, which will provide you all the UI pages (with gsps,controllers) just in a minute.
I have used this plugin in my project before one year, and I would strongly recommended everyone to use it...
You can have a look into its simple User guide which is available here.
Use one of the security plugins, and make the actions that you want to protect only available to users with a particular role. If an unauthenticated user tries to access one of these actions, they will be prompted to login and invocation of the action will only be allowed thereafter if they have been assigned the relevant role.
The spring security plugin is a reasonable choice as it provides the functionality you need and probably the most popular of the Grails security plugins.