Download the PHP package mrclay/shibalike without Composer
On this page you can find all versions of the php package mrclay/shibalike. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download mrclay/shibalike
More information about mrclay/shibalike
Files in mrclay/shibalike
Package shibalike
Short Description Provides a PHP library for emulating a Shibboleth environment.
License BSD-3-Clause
Homepage https://github.com/mrclay/shibalike
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package shibalike
Shibalike
Shibalike is a PHP library for emulating a limited Shibboleth
environment, and has components to query attributes for a user, persist them in a session (without interfering with native PHP sessions), and inject them into the $_SERVER array as would a web server module.
This allows you to use your own authentication system (based on any mechanism) and attribute provider to sign users into any app with an existing Shibboleth auth module.
Design
The design was based on this blog post, which laid out the initial concept. Unlike Shibboleth, Shibalike's SP ("Service Provider") and IdP ("Identity Provider") junction points must share a common backend storage (filesystem, DB, etc), and have access to each others' browser cookies. This limits the system's abilities to cross app boundaries, but also limits its complexity of implementation and setup.
Why Shibalike?
If you maintain a PHP app that relies on an institutional Shibboleth IdP:
- To test the app, you need a host with an SP and a blessing from the IdP:
- Getting SPs set up on developer machines (e.g. laptops) would be a hassle.
- Getting those laptops blessed by the IdP may be an ordeal, if possible.
- You don't control the IdP's behavior:
- You can't easily emulate downtime or flaky behavior for testing purposes.
- You can't easily see how your app handles a switch between shibboleth users.
- You can't quickly change arbitrary attributes for testing purposes.
- In a testing environment you can't simply sign in as a different Shibboleth user.
- You can't hardcode a user for use in unit/integration tests.
- The IdP can go down!
You could use Shibalike to setup a local "IdP" to be used during testing (e.g. the "login" might just be a dropdown of test users) or as a backup if the real IdP is down (e.g. the login might use LDAP or some other method to authenticate users).
You could even use Shibalike as an adapter between an app and a real Shibboleth system: Your local "IdP" would use Shibboleth to authenticate users, but you would specify how Shibalike presents those attributes to the application. E.g. once an "admin" user authenticates via Shibboleth, Shibalike could give him/her the option of signing into the app under a different user, or with altered attributes.
Why not SimpleSAMLphp?
You might want to checkout SimpleSAMLphp, an impressive native PHP implementation of SAML with some direct Shibboleth compatibility. It probably does 100 times as much as Shibalike, but also is heavier and significantly more complex. Shibalike's message passing is via shared backend storage; no XML/encryption/certs required.
Core Components
- IdP: allows marking a user as authenticated, or logging out the current user
- SP: allows injection of User attributes into
$_SERVER, and optional redirecting of user to your "login" app (using an IdP) - AuthRequest: value object set by the SP expressing desire to authenticate
- AuthResult: value object set by IdP with a valid user's username & attributes
- IStateManager (interface): stores Auth* objects associated with the current browser
- Attr\IStore (interface): provides attributes by username (e.g. from a DB)
UserlandSession
By default, Shibalike persists auth/user data in a non-native session component, which operates very similarly to native sessions, but which can be used independently of them. This allows Shibalike to maintain its state across applications without any interference with the native sessions used in those apps.
Completed Pieces
- Core behavioral pieces (SP, IdP).
- Interfaces for the state manager and attribute store.
- A default state manager, based on
UserLandSession. - A simple attribute provider based on Zend Db and a single table.
- A simple attribute provider based on a static array.
- A basic demo of a crude but operational usage.
License
Shibalike has a permissive, "modified BSD" license:
Copyright (c) 2011, Stephen Clay and other collaborators All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name Stephen Clay nor the names of his contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AFOREMENTIONED PARTIES BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
