zitadel / saml Goto Github PK

View Code? Open in Web Editor NEW

37.0 4.0 7.0 419 KB

A SAML 2.0 server (IdP) implementation written for Go

Home Page: https://zitadel.com

License: Apache License 2.0

JavaScript 0.03% Go 99.97%

idp saml2 authentication

saml's Introduction

SAML SDK (server) for Go

What is it

This project is a server implementation for the Security Assertion Markup Language (SAML) standard written for Go.

Basic Overview

The most important packages of the library:

/pkg
    /provider definitions and implementation of a SAML provider (Identity provider)
        /serviceprovider definitions and implementation of a SAML user (Service provider)
        /xml definitions of SAML xml messages
        /checker helper to abstract the SAML standard in the processes
        /signature implementation to handle and create SAML signature

Features

Supported SAML features:

Feature	Identity provider
POST-binding	yes
Redirect-binding	yes
Artifact-binding	no
Request signing	yes
Response signing	yes
Metadata signing	yes
Response encryption	no
Assertion Query/Request	no
Attribute Query	yes
NameID Mapping	no

Resources

For your convenience you can find the relevant standards linked below.

Supported Go Versions

For security reasons, we only support and recommend the use of one of the latest three Go versions (:white_check_mark:) .
Versions that also build are marked with ⚠️.

Version	Supported
<1.19	❌
1.19	⚠️
1.20	✅
1.21	✅

Why another library

As of 2021 there are only few SAML libraries, written in Go, which handle server and client implementations. As maintainer of github.com/zitadel/zitadel we are strongly committed to the general field of IAM (Identity and Access Management) and as such, we need solid frameworks to implement services.

The existing libraries that we evaluated were not implementing the standard strictly. For that reason we developed this project to be compliant to the standard, while still having the possibility to handle outliers.

For signing and signature verification other already existing implementations like github.com/russellhaering/goxmldsig(for POST-binding) and github.com/amdonov/xmlsig(for redirect-binding).

Other SAML libraries

https://github.com/crewjam/saml

Supports both IDP and SP side, whereas the IDP side is by their own definition only rudimentary.

https://github.com/russellhaering/gosaml2

Implementation of SP side with no IDP side, works with a lot of identity providers, also has an implementation of the XML signing which is used in this library.

https://github.com/RobotsAndPencils/go-saml

Only SP side, developed for several specific integrations with different IDPs, not an implementation for general SAML.

https://github.com/amdonov/lite-idp

Basic implementation of IDP side more as a standalone service, not that good to integrate into existing product.

License

The full functionality of this library is and stays open source and free to use for everyone. Visit our website and get in touch.

See the exact licensing terms here

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an " AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

saml's People

Contributors

Stargazers

Watchers

Forkers

coelho suryatmodulus baronrustamov lcpinto learnna-io luis-pinto-fanduel etienne-gh

saml's Issues

Support newer cryptographic algorithms for SAML signing and signature verification

Is your feature request related to a problem? Please describe.
This issue is to ask what the maintainers intend to do about cryptographic obsolescence to future-proof this project.

The https://github.com/amdonov/xmlsig library used by this project has not been updated for 6 years. It lacks current cryptographic algorithms and over time the algorithms it supports are likely to be undermined by cryptoanalytical attacks. In particular, SHA256 is the only modern hash algorithm supported: when that is deprecated (just as MD5 and SHA1 were before it), there are no other good options left to use, resulting in a risk of forgery of SAML responses allowing unauthorised access.

Describe the solution you'd like
Replace the old https://github.com/amdonov/xmlsig library with one that's actively maintained. Is there a reason for not using https://github.com/russellhaering/goxmldsig for all operations?

Describe alternatives you've considered
We can live with this for the time being, but long-term the only good option is to replace the obsolete library.

I have some background in cryptography and golang myself, if necessary I'd be willing to maintain a fork if that helps? e.g. see my PR here.

Additional context
Over time, cryptoanalysts develop new mathematical attacks against cryptographic algorithms and computing power continues to get cheaper. This results in cryptographic algorithms which are "good enough" today being deprecated over time. For example:

MD5 collisions
SHA1 collisions here and here

These have lead to deprecations of such algorithms, for example:

IETF RFC 9155
NIST SHA-1 deprecation (see also SP800-131A specifically Table 8)

It's very likely that the set of crypto algorithms in the XML signature libraries used here will one day become deprecated too.

This repository depends on two XML signature projects:

The goxmldsig library appears to be updated periodically and supports various newer algorithms such as SHA384 and SHA512.

However, https://github.com/amdonov/xmlsig has not had a commit for 6 years and does not appear to be maintained any more. It supports DSA and RSA encryption and SHA1 and SHA256 hashing only, omitting several newer algorithms included in the XML Signature Syntax and Processing Version 2.0 standard (from 2015) and the corresponding RFC 4051, notably ECDSA encryption and SHA384 and SHA512 hashing. It's a risk to rely on this obsolete library.

As noted above SHA1 is already deprecated, so SHA256 is the only viable signature algorithm for people concerned about cryptographic security. If a flaw is discovered in SHA256, users of Zitadel SAML won't have any available alternative algorithm to safely use. Cryptanalysis of the SHA2 family is already in progress. How long before it becomes deprecated too?

SAML IdP Response Encrypting

Description

Implement Encrypting of response

Acceptance criteria

SPs can receive encrypted SAML responses and decrypt them

SAML IdP Artifact-Binding

Description

Implement Auth-request with artifact-binding
Implement artifact-binding endpoint to resolve code to response

Acceptance criteria

Connect SPs with artifact-binding with ZITADEL

Invalid SubjectConfirmationData in generated assertion

Describe the bug
SubjectConfirmationData generated by this package contains NotBefore attribute, which is prohibited by the spec:

http://docs.oasis-open.org/imi/identity/imi-saml2.0-profile.html

2.3.4 Proof Keys and Subject Confirmation

The <saml:SubjectConfirmationData> element, if present, MUST NOT contain a NotBefore or Recipient XML attribute.

As a result, neither this package nor Zitadel itself can serve as IdP for SPs that enforce this rule. For instance, Jenkins SAML plugin -> https://github.com/pac4j/pac4j/blob/master/pac4j-saml/src/main/java/org/pac4j/saml/sso/impl/SAML2AuthnResponseValidator.java#L500-L502

To Reproduce
Steps to reproduce the behavior:

Deploy Jenkins with Jenkins SAML plugin
Link Jenkins to Zitadel as SAML SP
Try to sign in to Jenkins using SSO
See error in Jenkins logs

WARNINGo.j.p.saml.SamlSecurityRealm#doFinishLogin: Unable to validate the SAML Response: Subject confirmation validation failed

Expected behavior
SubjectConfirmationData must not contain a NotBefore attribute. I've tried removing it from https://github.com/zitadel/saml/blob/main/pkg/provider/response.go#L264 and can confirm that it works.

SAML Metadata for serviceproviders should also provide the necessary information

Is your feature request related to a problem? Please describe.
There is a function to unmarshal the metadata to a serviceprovider but it is not checked with the SPSSODescriptor that the metadata is also part of a serviceprovider.

Describe the solution you'd like
Check if the SPSSODescriptor is not empty with the necessary attributes.

Describe alternatives you've considered
Leave it as is, which could result in errors which are not really descriptive.