Python SSO: pysaml2 and python3-saml - python

I new to SSO and I've only tried pysaml2 by far.
I am also aware of python3-saml library (and its python-saml Python 2 flavour).
I need to use one of those with Shibboleth, if it is relevant.
What are the pros and cons of pysaml2 and python3-saml?
Update:
As for 2019, I still find python3-saml to be the best option if you need to implement an SP. It is not flawless (sorry #smartin, hhehe), but it will give you much less headache than pysaml2.

Both projects are compatible with Shibboleth.
pysaml2 is older than python3-saml, right now both support py2 and py3. Both are kinda active and documented.
python3-saml follows the structure of Onelogin's SAML toolkit so if you used any other toolkit before (php-saml, ruby-saml, java-saml), will be easy for you to handle with it (similar methods, same settings).
Differences
Crypto:
pysaml2 uses as dependecy pycryptodome to handle with cryptography and implements its own xmldsig and xmlenc classes (to manipulate signatures and encryption on XMLs).
python3-saml uses as dependecy python-xmlsec and delegates on it the signature/encryption of XML elements.
Functionality:
pysaml2 let you deploy an Identity Provider or a Service Provider
python3-saml is focused on the Service Provider
Settings:
In my opinion, python3-saml is easier than pysaml2, settings are more precise and its repo contains code examples on how integrate a django or a flask app and a guide at the docs.
Note: I'm the author of python3-saml

Related

OpenTelemetry API vs SDK

I'm confused as why OpenTelemetry documentaion has OpenTelemetry Python API and OpenTelemetry Python SDK.
Like when using the specification in python when we should consider pip install opentelemetry-api over pip install opentelemetry-sdk
From the github pages of the implementation.
(note: could not fit this into a comment and did not want to just post a link alone)
This repository includes multiple installable packages. The
opentelemetry-api package includes abstract classes and no-op
implementations that comprise the OpenTelemetry API following the
OpenTelemetry specification. The opentelemetry-sdk package is the
reference implementation of the API.
Libraries that produce telemetry data should only depend on
opentelemetry-api, and defer the choice of the SDK to the application
developer. Applications may depend on opentelemetry-sdk or another
package that implements the API.
In simple terms imagine a plain python or JAVA interface. An interface by itself is just a contract saying what all things it can do. But you cannot use that in your code anywhere without implementing the interface first. So interfaces are just abstract contracts(API) which needs to be have concrete implementations(SDK). It is only then can you use the SDK.
Such strategies normally help with unifying the implementations of software libraries across industry under a consistent and constant contract. There are multiple vendors out there like Datadog, New Relic, DynaTrace, Signoz and more who can now implement their own SDK if needed but at the same time comply with a standard contract that everyone abides by. This allows you as application developers to not get coupled to any one vendor. But have the option to choose the best one among them and make the swap when necessary without breaking anything in your software system.
Hope this helps answering why application may only depend on SDK.

Looking for Python API documentation for openstack load balancer component (Octavia)

I am looking for examples or actual documentation for Train level Openstack Octavia (Load Balancer component) python API. Everything in the OS project doc site seems to be focused on the CLI. I would like an example and possible API specification (what to pass in, what to expect out of the functions defined for the OctaviaAPI class in the component. I have been looking for a few hours with little success.
Try https://docs.openstack.org/openstacksdk/latest/user/proxies/load_balancer_v2.html. In general, projects' documentation sites don't cover Python bindings, as they are not part of the projects. OpenstackSDK is its own project.
Yeah, the client based python binds are being phased out in favor of the openstacksdk. Octavia went straight to using openstacksdk for the python bindings.

How to impersonate or delegate on kerberos with python?

I'm setting up a application on python that connects to hbase with thrift. This thrift connection uses kerberos as authentication with a service account, I need that the python application connect impersonating the user because my company uses kerberos with ad groups to restrict access to the tables on hbase.
This is an python 2.7 flask application running on linux.
I was taking a look at kerberos default library
https://github.com/apple/ccs-pykerberos/blob/master/pysrc/kerberos.py
and at line 159 I found this:
#param delegated: Optional server context containing delegated credentials
But I'm not familiar how to use this credentials.
I just want to be able to connect with hbase using impersonating.
Thanks.
P.S:I don't have much familiarity with kerberos so sorry for any misconceptions.
First you need to familiarize yourself with the concepts of delegation and constrained delegation. These are 2 different ways that Kerberos supports for "impersonation".
Short version: I recommend constrained delegation because it's more restricted. The only python library that I've been able to find that definitely supports constrained delegation is python-gssapi. I use this to impersonate users using constrained delegation and it works nicely.
Long version: There isn't a way to use Kerberos successfully without having a pretty good understanding of how it works at a high level. It isn't like anything else. You must first familiarize yourself with the essential concepts of Kerberos: tickets, principals, the KDC etc. Then, when you understand the language of Kerberos, you need to get familiar with the elements of the GSSAPI, and how they map to the Kerberos concepts you've learned. AFAIK, any python library you find out there for Kerberos is probably going to be a wrapper around the MIT krb5 libraries, which implement the GSSAPI spec. This is why I like the python-gssapi library: because it maps fairly closely to the underlying MIT libraries. That means I can usually figure out how to do stuff using the MIT documentation, and I can usually get help from the MIT mailing list if necessary.

What is the best way to support several API versions when using Python Eve?

I'm thinking of using Eve for the new project that I'm working on, but there's a requirement that there should be a way to introduce new API versions while still keeping the old ones. After reading the Eve documentation, I see that it doesn't really provide support for API versioning besides the ability to specify a version prefix in the config parameter.
What's the best way to implement the ability to support several API versions? The only way I can think of right now is to create a separate Eve app for each version and use application dispatching, but this seems overcomplicated to me...

Python3 OpenID-library

I search for OpenID-library, which works with python3. I need to be an OpenID-provider and OpenID-consumer. tornado.auth provides only consumer functionality. What I can use to implement provider functionality, or how it can be implemented with tornado?
Does anybody uses python3-openid (fork of python-openid)? How it works?
python3-openid is the Python 3 version of python-openid, which has been more or less the reference library for OpenID in Python for several years. So it should implement everything you need. (Disclaimer: I ported python3-openid over and am the maintainer of the PyPI package).
However, for Tornado you will need a non-blocking implementation, ideally using Tornado's HTTPClient classes, and currently python3-openid does not provide that -- if you'd like to implement it, though, I'll gladly work on your pull request!
I went with pyoidc because it is listed as a "Certified Relying Party Library" on the official list of "Certified OpenID Connect Implementations" directly on the website for the OpenID standard. It runs on Python 3.5+ and also doubles as a full OAuth2.0 implementation.
I know this is an old post but it is still relevant. One should not screw around when it comes to things like security and authentication, it could very well save your job to stick with officially recommended or certified libraries - if anything goes wrong, at least your choice of authentication library can't be called into question!
have you tried this, i found it on pypi:
http://pypi.python.org/pypi/python3-openid/3.0.1

Categories

Resources