Log in


Forgot your password?
New user?
 
You are here: Home

Modified items

All recently modified items, latest first.
RPMPackage python-ldapetl-1.1.1-2.lbn19.noarch
Provides ldapload and ldaptransform scripts alongside a range of useful and extensible infrastructure for performing large-scale LDAP migrations, loads etc
RPMPackage python-djangosaml2-0.11.0-1.lbn19.noarch
djangosaml2 is a Django application that integrates the PySAML2 library into your project. This mean that you can protect your Django based project with a service provider based on PySAML. This way it will talk SAML2 with your Identity Provider allowing you to use this authentication mechanism.
RPMPackage python-django-oauth2-provider-0.2.6.1-1.lbn19.noarch
django-oauth2-provider is a Django application that provides customizable OAuth2-authentication for your Django projects.
RPMPackage python-django-mellon-1.2.5-1.lbn19.noarch
SAML 2.0 authentication for Django Usage You need to have the Python binding for the Lasso library installed, you can find source and package for Debian on http://lasso.entrouvert.org/download/. Add mellon to your installed apps: INSTALLED_APPS = ( ... 'mellon', ) Add the SAMLBacked to your authentication backends: AUTHENTICATION_BACKENDS = ( ... 'mellon.backends.SAMLBackend', ) Add mellon urls to your urls: urlpatterns = patterns('', ... url(r'^/accounts/mellon', include('mellon.urls')), ) If SAML 2.0 should be your only authentication method you can define mellon_login as you main LOGIN_URL: LOGIN_URL = 'mellon_login' LOGOUT_URL = 'mellon_logout' Yout metadata will be downloadable through HTTP on http://youapplication/base/accounts/mellon/metadata If your identity provider ask for your assertion consumer URL it's on http://youapplication/base/accounts/mellon/login If your identity provider ask for your logout URL it's on http://youapplication/base/accounts/mellon/logout Session After an authentication attributes are stored in the session using a dictionnary, the key is mellon_session. The dictionnary contains: issuer: the EntityID of the identity provider name_id_content: the value of the NameID name_id_format: the format of the NameID authn_instant: the ISO8601 date of the authentication on the identity provider, optional. session_not_on_or_after: the ISO8691 date after which the local session should be closed. Note that we automatically set the expiration of the Django session to this value if it's available. authn_context_class_ref: the authentication method of the current authentication on the identity provider. You can restrict authorized authentication methods using the setting MELLON_AUTHN_CLASSREF. all attributes extracted from the assertion. Settings All generic setting apart from MELLON_IDENTITY_PROVIDERS can be overridden in the identity provider settings by removing the MELLON_ prefix. MELLON_IDENTITY_PROVIDERS A list of dictionaries, only one key is mandatory in those dictionaries METADATA it should contain the UTF-8 content of the metadata file of the identity provider or if it starts with a slash the absolute path toward a metadata file. All other keys are override of generic settings. MELLON_PUBLIC_KEYS List of public keys of this service provider, add multiple keys for doing key roll-over MELLON_PRIVATE_KEY The PKCS#8 PEM encoded private key, if not provided request will not be signed. MELLON_PRIVATE_KEY_PASSWORD Password for the private key if needed, default is None MELLON_NAME_ID_FORMATS NameID formats to advertise in the metadata file, default is (). MELLON_NAME_ID_POLICY_FORMAT The NameID format to request, default is None. MELLON_FORCE_AUTHN Whether to force authentication on each authencation request, default is False. MELLON_ADAPTER A list of class providings methods handling SAML authorization, user lookup and provisioning. Optional methods on theses classes are authorize(idp, saml_attributes) -> boolean If any adapter returns False, the authentication is refused. It's possible to raise PermissionDenied to show a specific message on the login interface. lookup_user(idp, saml_attributes) -> User / None Each adapter is called in the order of the settings, the first return value which is not None is kept as the authenticated user. provision(user, idp, saml_attributes -> None This method is there to fill an existing user fields with data from the SAML attributes or to provision any kind of object in the application. Settings of the default adapter The following settings are used by the default adapter mellon.adapters.DefaulAdapter if you use your own adapter you can ignore them. If your adapter inherit from the default adapter those settings can still be applicable. MELLON_REALM The default realm to associate to user created with the default adapter, default is 'saml'. MELLON_PROVISION Whether to create user if their username does not already exists, default is True. MELLON_USERNAME_TEMPLATE The template to build and/or retrieve a user from its username based on received attributes, the syntax is the one from the str.format() method of Python. Available variables are: realm idp (current setting for the idp issuing the assertion) attributes The default value is {attributes{name_id_content]}@realm. Another example could be {atttributes[uid][0]} to set the passed username as the username of the newly created user. MELLON_ATTRIBUTE_MAPPING Maps templates based on SAML attributes to field of the user model. Default is {}. To copy standard LDAP attributes into your Django user model could for example do that: MELLON_ATTRIBUTE_MAPPING = { 'email': '{attributes[mail][0]', 'first_name': '{attributes[gn][0]}', 'last_name': '{attributes[sn][0]}', } MELLON_SUPERUSER_MAPPING Attributes superuser flags to user if a SAML attribute contains a given value, default is {}. Ex.: MELLON_SUPERUSER_MAPPING = { 'roles': 'Admin', } MELLON_AUTHN_CLASSREF Authorized authentication class references, default is (). Empty value means everything is authorized. Authentication class reference must be obtained from your identity provider but SHOULD come from the SAML 2.0 specification. MELLON_GROUP_ATTRIBUTE Name of the SAML attribute to map to Django group names, default is None. Ex.: MELLON_GROUP_ATTRIBUTE = 'role' MELLON_CREATE_GROUP Whether to create group or only assign existing groups, default is True. MELLON_ERROR_URL URL for the continue link when authentication fails, default is None. If not ERROR_URL is None, the RelayState is used. If there is no RelayState, the LOGIN_REDIRECT_URL, which defaults to /, is used. MELLON_ERROR_REDIRECT_AFTER_TIMEOUT Timeout in seconds before automatically redirecting the user to the continue URL when authentication has failed. Default is 120 seconds.
RPMPackage python-django-authopenid-1.0.2-3.lbn19.noarch
Django authentification application with openid using django auth contrib. This application allow a user to connect to you website with a legacy account (username/password) or an openid url.
RPMPackage python-django-auth-ldap-1.2.2-1.lbn19.noarch
This is a Django authentication backend that authenticates against an LDAP service. Configuration can be as simple as a single distinguished name template, but there are many rich configuration options for working with users, groups, and permissions. Full documentation can be found at http://pythonhosted.org/django-auth-ldap/; following is an example configuration, just to whet your appetite: import ldap from django_auth_ldap.config import LDAPSearch, GroupOfNamesType AUTH_LDAP_SERVER_URI = "ldap://ldap.example.com" AUTH_LDAP_BIND_DN = "cn=django-agent,dc=example,dc=com" AUTH_LDAP_BIND_PASSWORD = "phlebotinum" AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=users,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(uid=%(user)s)") AUTH_LDAP_GROUP_SEARCH = LDAPSearch("ou=django,ou=groups,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(objectClass=groupOfNames)" ) AUTH_LDAP_GROUP_TYPE = GroupOfNamesType() AUTH_LDAP_REQUIRE_GROUP = "cn=enabled,ou=django,ou=groups,dc=example,dc=com" AUTH_LDAP_DENY_GROUP = "cn=disabled,ou=django,ou=groups,dc=example,dc=com" AUTH_LDAP_USER_ATTR_MAP = { "first_name": "givenName", "last_name": "sn", "email": "mail" } AUTH_LDAP_PROFILE_ATTR_MAP = { "employee_number": "employeeNumber" } AUTH_LDAP_USER_FLAGS_BY_GROUP = { "is_active": "cn=active,ou=django,ou=groups,dc=example,dc=com", "is_staff": "cn=staff,ou=django,ou=groups,dc=example,dc=com", "is_superuser": "cn=superuser,ou=django,ou=groups,dc=example,dc=com" } AUTH_LDAP_PROFILE_FLAGS_BY_GROUP = { "is_awesome": "cn=awesome,ou=django,ou=groups,dc=example,dc=com", } AUTH_LDAP_FIND_GROUP_PERMS = True AUTH_LDAP_CACHE_GROUPS = True AUTH_LDAP_GROUP_CACHE_TIMEOUT = 3600 AUTHENTICATION_BACKENDS = ( 'django_auth_ldap.backend.LDAPBackend', 'django.contrib.auth.backends.ModelBackend', )
RPMPackage python-django-allauth-authentic2-0.1.0.8-1.g0fb2965.lbn19.noarch
Authentic2 OAuth2 provider
RPMPackage python-django-allauth-0.18.0-1.lbn19.noarch
Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication. Home page http://www.intenct.nl/projects/django-allauth/ Source code http://github.com/pennersr/django-allauth Mailinglist http://groups.google.com/group/django-allauth Documentation http://django-allauth.readthedocs.org/en/latest/ Stack Overflow http://stackoverflow.com/questions/tagged/django-allauth Rationale Most existing Django apps that address the problem of social authentication focus on just that. You typically need to integrate another app in order to support authentication via a local account. This approach separates the worlds of local and social authentication. However, there are common scenarios to be dealt with in both worlds. For example, an e-mail address passed along by an OpenID provider is not guaranteed to be verified. So, before hooking an OpenID account up to a local account the e-mail address must be verified. So, e-mail verification needs to be present in both worlds. Integrating both worlds is quite a tedious process. It is definitely not a matter of simply adding one social authentication app, and one local account registration app to your INSTALLED_APPS list. This is the reason this project got started -- to offer a fully integrated authentication app that allows for both local and social authentication, with flows that just work. Commercial Support This project is sponsored by IntenCT. If you require assistance on your project(s), please contact us: info@intenct.nl.
RPMPackage python-authentic2-idp-oauth2-1.0.14-2.lbn19.noarch
Settings AUTOMATIC_GRANT: A list of URL prefix which are automatically granted scopes without asking the user. Example: A2_OAUTH2_AUTOMATIC_GRANT = ( ('http://localhost:8000/', ('read',)), ) Web Service proxy You can configure simple REST web-service in /admin/authentic2_idp_oauth2/webservice/. URL field can contain template variable like that: http://example.com/info/?user={{ user.username|urlencode }} or like: http://example.com/categories/?format=json&NameID={{ federations.service_1.links.0|urlencode }} Supported authentication mechanisms on the target web-service are HMAC-SHA-256 and HMAC-SHA-1 as specified on http://doc.entrouvert.org/portail-citoyen/dev/. You can access your newly proxy web-service through those URLs: http://your-idp.com/idp/oauth2/ws-proxy/<web-service.id>/ or: http://your-idp.com/idp/oauth2/ws-proxy/<web-service.slug>/
RPMPackage python-authentic2-auth-saml2-1.0.4-1.g01a1c2d.lbn19.noarch
Authentic2 SAML2 authentication plugin
RPMPackage python-authentic2-2.1.20-1.lbn19.noarch
Authentic 2 is a versatile identity provider aiming to address a broad range of needs, from simple to complex setups; it has support for many protocols and can bridge between them. Authentic 2 is under the GNU AGPL version 3 licence. It has support for SAMLv2 thanks to Lasso, a free (GNU GPL) implementation of the Liberty Alliance specifications. Full documentation available on http://packages.python.org/authentic2. Features -------- Authentic can authenticate users against: - an LDAP directory, - a SAML 2.0 identity provider, - an OpenID identity provider, - with an X509 certificate. Authentic can provide authentication to web applications using the following protocols: - OpenID, - SAML 2.0, - CAS 1.0 & CAS 2.0. Authentic can proxy authentication between any two different protocols it support.
RPMPackage pyldb-1.1.26-1.lbn19.x86_64
Python bindings for the LDB library
RPMPackage pyldb-1.1.26-1.lbn19.x86_64
Python bindings for the LDB library
RPMPackage pyldb-1.1.16-1.fc19.armv6hl
Python bindings for the LDB library
RPMPackage pyDes-2.0.1-1.lbn19.noarch
This algorithm is a pure python implementation of the DES and Triple DES algorithms. Triple DES is either DES-EDE3 with a 24 byte key, or DES-EDE2 with a 16 byte key.
RPMPackage pki-symkey-10.0.7-1.fc19.x86_64
The Symmetric Key Java Native Interface (JNI) package supplies various native symmetric key operations to Java programs. This package is a part of the PKI Core used by the Certificate System. ================================== || ABOUT "CERTIFICATE SYSTEM" || ================================== Certificate System (CS) is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. PKI Core contains ALL top-level java-based Tomcat PKI components: * pki-symkey * pki-base * pki-tools * pki-selinux (f17 only) * pki-server * pki-ca * pki-kra (fedora only) * pki-ocsp (fedora only) * pki-tks (fedora only) * pki-javadoc which comprise the following corresponding PKI subsystems: * Certificate Authority (CA) * Data Recovery Manager (DRM) (fedora only) * Online Certificate Status Protocol (OCSP) Manager (fedora only) * Token Key Service (TKS) (fedora only) For deployment purposes, PKI Core contains fundamental packages required by BOTH native-based Apache AND java-based Tomcat Certificate System instances consisting of the following components: * pki-tools * pki-selinux (f17 only) Additionally, PKI Core contains the following fundamental packages required ONLY by ALL java-based Tomcat Certificate System instances: * pki-symkey * pki-base * pki-tools * pki-server PKI Core also includes the following components: * pki-javadoc Finally, if Certificate System is being deployed as an individual or set of standalone rather than embedded server(s)/service(s), it is strongly recommended (though not explicitly required) to include at least one PKI Theme package: * dogtag-pki-theme (Dogtag Certificate System deployments) * dogtag-pki-server-theme * redhat-pki-server-theme (Red Hat Certificate System deployments) * redhat-pki-server-theme * customized pki theme (Customized Certificate System deployments) * <customized>-pki-server-theme NOTE: As a convenience for standalone deployments, top-level meta packages may be provided which bind a particular theme to these certificate server packages.
RPMPackage pki-symkey-10.0.7-1.fc19.x86_64
The Symmetric Key Java Native Interface (JNI) package supplies various native symmetric key operations to Java programs. This package is a part of the PKI Core used by the Certificate System. ================================== || ABOUT "CERTIFICATE SYSTEM" || ================================== Certificate System (CS) is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. PKI Core contains ALL top-level java-based Tomcat PKI components: * pki-symkey * pki-base * pki-tools * pki-selinux (f17 only) * pki-server * pki-ca * pki-kra (fedora only) * pki-ocsp (fedora only) * pki-tks (fedora only) * pki-javadoc which comprise the following corresponding PKI subsystems: * Certificate Authority (CA) * Data Recovery Manager (DRM) (fedora only) * Online Certificate Status Protocol (OCSP) Manager (fedora only) * Token Key Service (TKS) (fedora only) For deployment purposes, PKI Core contains fundamental packages required by BOTH native-based Apache AND java-based Tomcat Certificate System instances consisting of the following components: * pki-tools * pki-selinux (f17 only) Additionally, PKI Core contains the following fundamental packages required ONLY by ALL java-based Tomcat Certificate System instances: * pki-symkey * pki-base * pki-tools * pki-server PKI Core also includes the following components: * pki-javadoc Finally, if Certificate System is being deployed as an individual or set of standalone rather than embedded server(s)/service(s), it is strongly recommended (though not explicitly required) to include at least one PKI Theme package: * dogtag-pki-theme (Dogtag Certificate System deployments) * dogtag-pki-server-theme * redhat-pki-server-theme (Red Hat Certificate System deployments) * redhat-pki-server-theme * customized pki theme (Customized Certificate System deployments) * <customized>-pki-server-theme NOTE: As a convenience for standalone deployments, top-level meta packages may be provided which bind a particular theme to these certificate server packages.
RPMPackage pki-symkey-10.0.4-2.fc18.armv6hl
The Symmetric Key Java Native Interface (JNI) package supplies various native symmetric key operations to Java programs. This package is a part of the PKI Core used by the Certificate System. ================================== || ABOUT "CERTIFICATE SYSTEM" || ================================== Certificate System (CS) is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. PKI Core contains ALL top-level java-based Tomcat PKI components: * pki-symkey * pki-base * pki-tools * pki-selinux (f17 only) * pki-server * pki-ca * pki-kra (fedora only) * pki-ocsp (fedora only) * pki-tks (fedora only) * pki-javadoc which comprise the following corresponding PKI subsystems: * Certificate Authority (CA) * Data Recovery Manager (DRM) (fedora only) * Online Certificate Status Protocol (OCSP) Manager (fedora only) * Token Key Service (TKS) (fedora only) For deployment purposes, PKI Core contains fundamental packages required by BOTH native-based Apache AND java-based Tomcat Certificate System instances consisting of the following components: * pki-tools * pki-selinux (f17 only) Additionally, PKI Core contains the following fundamental packages required ONLY by ALL java-based Tomcat Certificate System instances: * pki-symkey * pki-base * pki-tools * pki-server PKI Core also includes the following components: * pki-javadoc Finally, if Certificate System is being deployed as an individual or set of standalone rather than embedded server(s)/service(s), it is strongly recommended (though not explicitly required) to include at least one PKI Theme package: * dogtag-pki-theme (Dogtag Certificate System deployments) * dogtag-pki-server-theme * redhat-pki-server-theme (Red Hat Certificate System deployments) * redhat-pki-server-theme * customized pki theme (Customized Certificate System deployments) * <customized>-pki-server-theme NOTE: As a convenience for standalone deployments, top-level meta packages may be provided which bind a particular theme to these certificate server packages.
RPMPackage pki-ca-10.0.7-1.fc19.noarch
The Certificate Authority (CA) is a required PKI subsystem which issues, renews, revokes, and publishes certificates as well as compiling and publishing Certificate Revocation Lists (CRLs). The Certificate Authority can be configured as a self-signing Certificate Authority, where it is the root CA, or it can act as a subordinate CA, where it obtains its own signing certificate from a public CA. This package is one of the top-level java-based Tomcat PKI subsystems provided by the PKI Core used by the Certificate System. ================================== || ABOUT "CERTIFICATE SYSTEM" || ================================== Certificate System (CS) is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. PKI Core contains ALL top-level java-based Tomcat PKI components: * pki-symkey * pki-base * pki-tools * pki-selinux (f17 only) * pki-server * pki-ca * pki-kra (fedora only) * pki-ocsp (fedora only) * pki-tks (fedora only) * pki-javadoc which comprise the following corresponding PKI subsystems: * Certificate Authority (CA) * Data Recovery Manager (DRM) (fedora only) * Online Certificate Status Protocol (OCSP) Manager (fedora only) * Token Key Service (TKS) (fedora only) For deployment purposes, PKI Core contains fundamental packages required by BOTH native-based Apache AND java-based Tomcat Certificate System instances consisting of the following components: * pki-tools * pki-selinux (f17 only) Additionally, PKI Core contains the following fundamental packages required ONLY by ALL java-based Tomcat Certificate System instances: * pki-symkey * pki-base * pki-tools * pki-server PKI Core also includes the following components: * pki-javadoc Finally, if Certificate System is being deployed as an individual or set of standalone rather than embedded server(s)/service(s), it is strongly recommended (though not explicitly required) to include at least one PKI Theme package: * dogtag-pki-theme (Dogtag Certificate System deployments) * dogtag-pki-server-theme * redhat-pki-server-theme (Red Hat Certificate System deployments) * redhat-pki-server-theme * customized pki theme (Customized Certificate System deployments) * <customized>-pki-server-theme NOTE: As a convenience for standalone deployments, top-level meta packages may be provided which bind a particular theme to these certificate server packages.
RPMPackage perl-Net-OpenID-Server-1.09-3.lbn19.noarch
This is the Perl API for (the server half of) OpenID, a distributed identity system based on proving you own a URL, which is then your identity. More information is available at: http://openid.net/ As of version 1.01 this module has support for both OpenID 1.1 and 2.0. Prior to this, only 1.1 was supported.
 
Distributions
To see exactly what is included in BastionLinux™, visit our online RPMDistro Builder.
Buy Now
Bastion CD
Subscribe Now and get BastionLinux™ ...
Sponsored Links