Projects tagged ‘cas’


[13 total ]

47USERS
   

A full-featured, Free Source Software (GNU/LGPL), multilingual, Wiki/CMS/Groupware hybrid written in PHP and maintained by an active and international community of volunteer contributors. Major features include articles, forums, newsletters ... [More] , blogs, a file/image gallery, a Wiki, drawing, trackers, a directory, polls/surveys and quizzes, a FAQ, chat, a banner management system, a calendar, maps, charts, Mobile Tiki (PDA and WAP access), RSS feeds, a category system, a theme control center, workflow engine, live support, Shoutbox, ACLs, and more. The project is LGPL. The notes below about "may conflict with GPL" are caused because TikiWiki includes tripled licensed code. Please see: http://www.ohloh.net/forums/10/topics/1730 Tiki started in October 2002 (ohloh stats are not yet updated) [Less]

37USERS
   

Liferay Portal is the world's leading enterprise open source portal framework, offering integrated Web publishing and content management, an enterprise service bus and service-oriented architecture, and compatibility with all major IT infrastructures.

21USERS
   

JBoss Portal provides an open source platform for hosting and serving a portal's Web interface, publishing and managing its content, and customizing its experience.

13USERS
   

The CAS Server is a Java-based enterprise single sign on solution. Client support includes Java, PL/SQL, Apache, PHP, Perl and more.

5USERS
   

Lemonldap::NG is a modular Web-SSO based on Apache::Session modules. It simplifies the build of a protected area with a few changes in the application. It manages both authentication and authorization and provides headers for accounting. So you can ... [More] have a full AAA protection for your web space as described below. Lemonldap::NG is a complete rewrite of Lemonldap. All components needed to use it and to aminister it are included in the tarball. Contrary, all modules developed for Lemonldap may not work with Lemonldap::NG. [Less]

5USERS
 

RubyCAS-Client is a Ruby client for Yale's Central Authentication Service protocol -- an open source enterprise single sign on system for web applications.

4USERS
 

This Google Code project exists as a fork of what was originally the Yale Java CAS Client (and prior to that, the Java portion of the general Yale CAS Client library). Subsequently, the JA-SIG CAS project, primarily Scott Battaglia, have brought ... [More] into being a JA-SIG Java CAS Client. That is a Good Thing. It's next-generation. It's Springy. It's got shared source control and a maintenance stream. Go use that. However, that codebase does have a bit of an impedance mismatch for folks used to using the legacy CAS client. Where can the legacy folks track bugs, build out documentation, collaborate in shared source control, or just reliably get this code? Where can this code live? This is intended to be that place. [Less]

4USERS
 

RubyCAS-Server is a Ruby implementation of a server for Yale's Central Authentication Service. CAS provides single sign-on authentication for web applications. Since CAS is a solid, widely-adopted protocol, CAS clients are available for many ... [More] platforms and frameworks, including Java, PHP, Ruby on Rails, and others. RubyCAS-Server is designed to be simple to set up and configure (which is quite the opposite from it's popular Java cousin, the JA-SIG CAS Server). RubyCAS-Server is written using the Camping microframework. Code contributions are welcome. Please contact the author for access to the subversion repository. [Less]

3USERS

BioWebAuth (Biometrics for Web Authentication) is an open source Java framework intended to provide single sign-on web authentication based on BioAPI-compliant biometric software or devices. It uses the JA-SIG Central Authentication Service architecture.

1USERS

An alternative Central Authentication Service server. It is implemented in Jifty using Perl.

1USERS

Console scientific calculator which support know : cos,atan,ln,exp,derive,prime test,... It works on Windows and Linux.

1USERS
 

Math::Symbolic is intended to offer symbolic calculation capabilities to the Perl programmer without using external (to Perl) libraries and/or applications. It's quite limited in scope. No integration of expressions, for example. However, various ... [More] extensions have been written to allow things like symbolic tree transformations using declarative syntax or compilation to Perl or C code for faster numeric evaluation. [Less]

0USERS

Django CASdjango_cas is a CAS 1.0 and CAS 2.0 authentication backend for Django. It allows you to use Django's built-in authentication mechanisms and User model while adding support for CAS. It also includes a middleware that intercepts calls to ... [More] the original login and logout pages and forwards them to the CASified versions, and adds CAS support to the admin interface. InstallationRun python setup.py install, or place the django_cas directory in your PYTHONPATH directly. (Note: If you're using Python 2.4 or older, you'll need to install ElementTree to use CAS 2.0 functionality.) Now add it to the middleware and authentication backends in your settings. Make sure you also have the authentication middleware installed. Here's what mine looks like: MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django_cas.middleware.CASMiddleware', 'django.middleware.doc.XViewMiddleware', ) AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', 'django_cas.backends.CASBackend', )Set the following required setting in settings.py: CAS_SERVER_URL: This is the only setting you must explicitly define. Set it to the base URL of your CAS source (e.g. http://sso.some.edu/cas/). Optional settings include: CAS_ADMIN_PREFIX: The URL prefix of the Django administration site. If undefined, the CAS middleware will check the view being rendered to see if it lives in django.contrib.admin.views. CAS_IGNORE_REFERER: If True, logging out of the application will always send the user to the URL specified by CAS_REDIRECT_URL. CAS_LOGOUT_COMPLETELY: If False, logging out of the application won't log the user out of CAS as well. CAS_REDIRECT_URL: Where to send a user after logging in or out if there is no referrer and no next page set. Default is /. CAS_VERSION: The CAS protocol version to use. '1' and '2' are supported, with '2' being the default. Make sure your project knows how to log users in and out by adding these to your URL mappings: (r'^accounts/login/$', 'django_cas.views.login'), (r'^accounts/logout/$', 'django_cas.views.logout'),Users should now be able to log into your site (and staff into the administration interface) using CAS. Populating User DataTo add user data, subclass CASBackend and specify that as your application's backend. For example: from django_cas.backend import CASBackend class PopulatedCASBackend(CASBackend): """CAS authentication backend with user data populated from AD""" def authenticate(self, ticket, service): """Authenticates CAS ticket and retrieves user data""" user = super(PopulatedCASBackend, self).authenticate( ticket, service) # Connect to AD, modify user object, etc. return userPreventing Infinite RedirectsDjango's current implementation of its permission_required and user_passes_test decorators (in django.contrib.auth.decorators) has a known issue that can cause users to experience infinite redirects. The decorators return the user to the login page, even if they're already logged in, which causes a loop with SSO services like CAS. django_cas provides fixed versions of these decorators in django_cas.decorators. Usage is unchanged, and in the event that this issue is fixed, the decorators should still work without issue. For more information see http://code.djangoproject.com/ticket/4617. Customizing the 403 Error PageDjango doesn't provide a simple way to customize 403 error pages, so you'll have to make a response middleware that handles HttpResponseForbidden. For example, in views.py: from django.http import HttpResponseForbidden from django.template import RequestContext, loader def forbidden(request, template_name='403.html'): """Default 403 handler""" t = loader.get_template(template_name) return HttpResponseForbidden(t.render(RequestContext(request)))And in middleware.py: from django.http import HttpResponseForbidden from yourapp.views import forbidden class Custom403Middleware(object): """Catches 403 responses and renders 403.html""" def process_response(self, request, response): if isinstance(response, HttpResponseForbidden): return forbidden(request) else: return responseNow add yourapp.middleware.Custom403Middleware to your MIDDLEWARE_CLASSES setting and create a template named 403.html. CAS 2.0 supportThe CAS 2.0 protocol is supported in the same way that 1.0 is; no extensions or new features from the CAS 2.0 specification are implemented. elementtree is required to use this functionality. (elementtree is also included in Python 2.5's standard library.) Note: The CAS 3.x server uses the CAS 2.0 protocol. There is no CAS 3.0 protocol, though the CAS 3.x server does allow extensions to the protocol. Differences Between Django CAS 1.0 and 2.0Version 2.0 of django_cas breaks compatibility in some small ways, in order simplify the library. The following settings have been removed: CAS_LOGIN_URL and CAS_LOGOUT_URL: Version 2.0 is capable of determining these automatically. CAS_POPULATE_USER: Subclass CASBackend instead (see above). CAS_REDIRECT_FIELD_NAME: Django's own REDIRECT_FIELD_NAME is now used unconditionally. [Less]