IdentityPython

(Heather Flanagan)

Heather: Identity python is a set of projects to provide some key ID management infrastructures based on python tools. The reason for these tools is to simplify the process and provide a bridge from SAML to OIDC. Why would there be a bridge between these two things?

One of the fundamentals of SAML is RSA Crypto which has its own properties. What if it would be broken, what are your options?

1. Replacing underlying cryptography (e.g. elliptic curves)
2. Switching into a whole new set of tools.

Different components: OIDC related tools (open sourced)

SATOSA: Tends to be useful in the IDentity concepts. A proxy that helps managing the flow of info. It can improve signing

SATOSA can reduce the fear of not understandable error messages

Rainer: It is interesting why a proxy would be in a better position to improve this error msg?

H: It depends from where the error is happening – IDP messages can be poor for example and relying only on the IDP to get it right is not always the right approach

Mischa: This is one of the usual scenarios why proxies are being used nowadays

H: I remember when proxies were not the prime solution

Peter: It is now the solution for everything basically

PyFF: Purely a workflow process with the intent to aggregate validate and transform SAML metadata. It works very well with making identity provisioning healthier. Other user cases are for transforming metadata for custom info, federation purposes, generating reports from metadata,

PySAML - A thought experiment according to Roland regarding how it should work in real code H: IPv4 is a good analogy for PySAML since it was also not initially thought for this level of distribution it has today

It is an important component for SAML as a technology on its own.

Open ID connect - PyOP is a wrapper for OIDC, being replaced by a new library sponsored by google.

Roland: You rarely get the chance to start all over about a certain implementation. Used code from PyOC implementation and improved it with the goal of

Google is putting money into building three big libraries: python java and JavaScript. They should through APIs provide a configuration that ensures these libraries will work as safely as possible by default Any changes have to be later put in - this is something being changed now with my python implementation

H: All of these things are very well connected with one another but in terms of coordinating them and making place for IPR and keeping it open source and fully supported There are several possible IPR homes and we are in the process of picking the best criteria for them. This issue has broader implication for the projects. The open ID pieces are the biggest discussion right now among us and we are trying to keep all the pieces in one place fundamentally. Contracts have to be signed and all contributors have yet to agree to one common home. There is a Github repository for the project: Github/IdentityPython

When do you hope to have the agreements?

H: I would like to have that until May. Not sure how realistic it is for everything for at least to have full community outreach and signing of the CLAs.

Many people to sign?

Rainer: 108 email addresses i think – still need to be checked

Ralf: Why do you need the CLA in the first place?

H: Because whatever they have contributed might still need to be changed

Rainer: It is a safeguard for all kinds of issues for the contributors as well.

Ralf: Does that put them under your protections as contributors?

H: Yes also that.

The standard does not omit different tech so we could use elliptic curve for example? The whole SAML ecosystem is quite large so this is right now being seen as a hurdle for this possibility. Roland: In the early 2000s there were very well understood problems with XML such as normalization and about that time (2004) there was a proposal to sign the XML and provide a non-normalized text parallel to it. Not many have implemented it unfortunately even though it solved many of these issues. So even if you can, enforcing implementation is problematic.

H: From the point of view of an IT manager it is often easier to replace a system rather than upgrade / improve it

Ralf: Does that mean that when a protocol has reached a certain age does it make sense to change it?

Rainer: We have to kind of since we have a new generation of engineers who don’t understand it the old version practically

H: I think we have learnt a lot from SAML

Roland: Same from Ipv for example. There are a few outdated but still very good solutions

Mischa: How does SATOSA compare to other solutions? Roland: I am not sure at this time. Haven’t looked at many others.

Rainer: There was a discussion about what base to put into it. SATOSA is practically a lean code base, easily configurable. Not sure you can do the same with Ship IP and how much payload they have coming with it. Once SATOSA is mature it should be more secure and reliable since it is still in an early stage

Roland: It has been around for only 5-6 years

Peter: It also depends what other analogues are in the environment. That also helps in the choice for a proxy. Even for harder software to configure, you can use glue code.

Rainer: 4shark for example i am not sure it is that easily adjustable.

In our federation we have to rewrite the metadata generation tool. Would you say the bundle is in the state where we can actually use it?

H: You wouldn’t be the first. It is being used in all kinds of places.

Rainer: For example in the Aquanet

So basically the tools are already in production but the problem right now is to put it under one name?

H: Mostly yes. The Pyff work has a lot of support from the publishing community right now for example but also architects have a great interest

Do we have enough resources to work on ID Python?

H: Never. However there are several reasons to put all the tools under one umbrella and one of them being lack of resources- the ability to assign them strategically

Good to see that a request into it would be responded to and taken into consideration H: One of the things we discovered is that different use cases are very interesting and they have common grounds often enough Ralf: I think an open discussion also helps to have a healthy community feedback

If we are all under the same umbrella it makes it easier to respond to the community requests with all available tools also.

Peter: How is the whole thing funded / the sustainability aspect related to it?

H: It is just insider contribution so far and there is no legal home for it yet. Everyone is pitching in so far in donations. That is what we’re doing with finding IPR homes, also for that reason. The legal aspect of it.

Rainer: It is being seen as an existing legal entity rather than a new independent one

H: Mostly it is being requested into the version of an incubator. Not long term protected

Peter: There are successful examples though of cases that are sustainable for open source projects with single contributions

Roland: It is important to have a whole community where people can contribute both money and time, so that is also why a legal entity is needed. Another reason is that there should be a legacy and smooth transitioning from one generation to another.