I have a three applications that I would like to keep separate for manageability purposes. They run as a Plack server as suggested here, proxied behind nginx.
I would like to have a separate application to manage logins, and have that login and its authentication process shared across all other apps, with authorization done via roles.
I would like to use Catalyst::Authentication::Store::DBIx::Class for storage.
I have tried managing authentication at the Plack level with Catalyst::Authentication::Credential::Remote doing it at the Catalyst level (which would be ideal), but can't seem to make the login seen by the Catalyst apps.
Thanks for your help.
Sharing the store is easy -- you can either just use the DBIC session store and duplicate the config in all of the apps, or you can create a subclass of the DBIC store with a __PACKAGE__->config line containing the stuff that all of the apps have in common, and then specify your subclass in the session config.
As for the state -- you can use State::Cookie if the apps share a domain in common -- you just need to set the cookie_domain and/or cookie_path options in your session config so that the cookie gets set in a way that it will be visible to all of the apps, and set the cookie_name config option to the same thing in all apps, because otherwise they would all get different cookie names based on their different application class names.
Related
I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.
I'm looking at some (PHP) Frameworks, and I just noticed this in the Laravel documentation:
Like most web-development frameworks, Laravel is designed to protect your application code, bundles, and local storage by placing only files that are necessarily public in the web server's DocumentRoot. This prevents some types of server misconfiguration from making your code (including database passwords and other configuration data) accessible through the web server. It's best to be safe.
I'm familiar with CodeIgniter and CakePHP, as far as I know, these two frameworks don't do this. Should you really split it up and place your core logic outside of the webroot? In my experience, most clients use shared hosting and are not able to change their VirtualHost settings.
What kind of misconfiguration could you possibly do that would output your passwords? When developing, should you really do this?
Yes, keeping only those files which should be publicly accessible in DocumentRoot is a best practice for web application security. Consider:
Every file which is private would need a rule configured with the web server to explicitly block it.
Anyone adding files to the project needs to consider web server security settings. Simply keeping the files in separate directories makes it obvious what's public. And developers don't need to change security configurations.
Separating executable code and static files is a good practice anyway.
Not blocking access to PHP scripts can cause unintended consequences. For example, you may have a script to update some DB records when run manually at the command line, so someone simply guessing a script name can run it over the internet.
Monitoring for and cleaning malicious code written to the public directory is much easier if the real application logic is elsewhere. See Wordpress breakins for an example.
CakePHP supports this - see deployment:
CakePHP applications should have the document root set to the
application’s app/webroot. This makes the application and
configuration files inaccessible through a URL.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.
I'm trying to clone a commercial Student Management System which was written in Perl. I want to use PHP, as I have no experience in Perl.
I am now trying to set up the login system, which should be (has to be?) done with PHPSESSID's, right? Now, in PHP I could transmit the Session ID via GET, POST, and COOKIE.
The Perl website doesn't add parameters to the URL (GET) and does not save cookies on my computer (COOKIE). There is also no form which could contain a hidden field (which would be POST in PHP, right?)
Can someone tell me how Perl remembers the logged in user there?
Perl takes a much more "toolkit"-based approach to building web applications than PHP does, because Perl was not designed specifically for web work. So it doesn't have any built-in way of doing web app session management; rather, there are many modules on CPAN which implement session management in many different ways.
If you were to identify the Student Management System in question and provide a URL, we might be able to look at it from the outside and identify what it's doing, but, really, I question whether you actually need to use the same session management system as the existing app unless you want to implement single-sign-on between the original version and your clone[1]. Concentrate on cloning the user-visible interface and functionality rather than the implementation details behind it.
[1] ...which would be futile anyhow unless you're also planning to tap into its session database on the back end, since neither one will recognize the other's session ids if they don't share that data.
For the sake of completeness, there are OTHER, non-standard ways to store/transmit session information than the 3 methods you listed (although I seriously doubt any of them are used in your SMS). Among them:
Sending the cookie data as part of the DOM (e.g. in HTML) and having on-page JavaScript access it from DOM
Or, just store the cookied data as JavaScript's data in the first place.
AJAX calls. E.g. the session-enabled logic is all handled in AJAX URLs and not the main URLs. Yes, I know that's completely screwy. But doable.
Don't store the cookie in main cookie database (so you can't find it using standard cookie viewing methods). For details on how that's done, please google "evercookie" for a VERY cool method of persistently storing cookie info by utilizing up to 10 redundant storage options - one good intro is http://blog.depthsecurity.com/2010/09/super-persistent-cookies-evercookie.html
All that said, I completely agree with Dave's answer - just use PHP's best practices mechanism to implement the functionality instead of cloning possibly-perl-specific and possibly-weird implementation in the webapp.