Zend Auth, if you want to secure a Zend Framework app, along with Zend Acl, it's essential. But do you know what it is? Do you know how to use it? Do you know how to extend it? Through this series I'm going to show you how to do all three.
One of the reasons that I'm such a fan of the Zend Framework over many others, whether Kohana, Symfony, Prado or Yii or one of the other exceptional frameworks, is because of the dead-simple extendability of the core libraries.
Zend Framework – So Extendable
You can accept and use the core Zend Framework libraries as they are and you'll get along just fine; but from time to time, you are inevitably going to run up against circumstances where you need more, different, custom or quirky, once-off functionality.
Whether you want to authenticate against Amazon S3 or Twitter, retrieve data from Redis, or interact with ZeroMQ, Zend provides a really simple path to extensibility.
So, for me, despite the oft derided performance issues associated with the Zend Framework, it's design makes it very customisable and extendable in a clear, systematic and logical way. And for me, that more than makes up for other considerations. This is primarily because I like things neat, tidy and ordered and for me, it provides that in abundance.
So on Tuesday, the 21st June, I'm beginning a series looking at different ways in which Zend Framework can be extended and configured to take on different circumstances of authentication.
In the series I'm going to look at the Zend_Auth classes, specifically how to extend them and in the process take you from beginner to pro (well, sorta). I'm going to start off by covering the basics of the classes and its approach to application authentication.
Then I'll show you how to extend it and create a set of different adapters in addition to the existing 5 (Database, Digest, HTTP, LDAP and OpenID).
Part 1 - A Testing/Mock Adapter
The first is going to be a test adapter that accepts a default username and password, which are hard-coded as class constants. Now I hear what you're saying – that's wrong; but imagine a test situation where you are not connecting to a database, an LDAP directory, a configuration file, or a HTTP server – you want to mock the situation out.
All you want to know is that you can make the call and move on. In this situation this type of adapter would be ideal for your needs as you want to test functionality around it. So we're not going to get too caught up in semantic issues, but use it to cover the basics of extending Zend Auth.
Part 2 - A Zend Config Adapter
Then, in part 2, we're going to get a bit more advanced and extend the classes to create a Zend_Config-based authentication class. Whether you're a fan of INI, XMLl, YAML **or JSON**, you can use any or all of them by the end of the second post to store user details (not that you likely would) to authenticate your users against. This kind of adapter would be great for simple purposes, smaller company intranets or small business purposes. Not a great use of security however.
Part 3 - A NoSQL Adapter with MongoDB
Finally, in part 3, we're going to take it further and use MongoDB to authenticate against. Yep, unless you have your head underneath a rock these days you've heard of NoSQL and along with that, MongoDB.
Given that rapid growth in acceptance and popularity, it's only right that we consider that too. But whilst we're on the point, have you ever considered using NoSQL databases as a backend to your authentication work? Have you ever thought of using Cassandra, Redis, Hbase or Membase?
If not, maybe you should. You get features covering versioning, automatic caching, sharding and replication, depending on the database implementation you choose. They're something to really behold – and they're still early in their developing years. If you're considering them, stick around for this one – it's sure to whet your appetite for more.
If you liked what you read and would like to see more, please retweet it, or give it a like on Facebook or even give it some Digg love. And we always value you feedback and comments.