Provide option for use SAML authentication

[ddudzinski]

My company looking for integration with SAML for authentication and great if this can be added to the roadmap.

[jessehu]

@ddudzinski is this high priority for your company ?

[ddudzinski]

@jessehu Yes this is high priority for us.

[jessehu]

@ddudzinski Great. Could you please let me know what is your company and how your use case for Harbor? We can connect you with our PM and get this SAML feature planned. My email is huh@vmware.com, in case you need it.

[ghost]

Hi @ddudzinski – thanks for the feedback. This is on our roadmap, but we'd love a PR or two to help with the implementation. 👍

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mkj28]

Does commenting on it prevent it from being closed?

[mogul]

I'm also looking for SAML or OIDC integration (and posting to keep the issue from staling out). My use case is to authenticate access to Harbor using Cloud Foundry's UAA as an identity hub.

[mogul]

Never mind, I see that UAA support was explicitly added in 1.4.0. Will open a separate issue about docs.

[cafeliker]

I am looking for the SAML integration feature as well, as our cyber security asks for all the applications need to integrate with PingFederate for authentication purpose.

[sykp241095]

SAML+1

[balonik]

SAML please

[billabongrob]

Our enterprise would greatly benefit from SAML as well.

[Zenithar]

+1

[gozer2222]

+1

[julioelblanco]

+1

[ZeBidule]

+1

[Zenithar]

Maybe support external authentication via HTTP headers, in order to delegate SAML/OIDC/Kerberos/etc... authentication via reverse proxy.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mkj28]

plz don't close

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[metri]

don't close

[tstrohmeier]

+1 for SAML or OIDC

[futare]

+1 for SAML

[timcappalli]

I am looking for the SAML integration feature as well, as our cyber security asks for all the applications need to integrate with PingFederate for authentication purpose.

PingFed supports OIDC which is supported in Harbor.

[rhyssmith]

+1 for SAML, or external authentication via HTTP headers so we can do SAML externally.

[JasonEverling]

+1

[brtduvally]

+1 for SAML. We don't want to have to put this behind a jumpbox like we have to do for vSphere.

[teamktown]

+1 for SAML or external headers per comment above by @rhyssmith

[sota0113]

+1 for SAML.

[xaleeks]

@reasonerjt reviving this, still lots asking for saml

[kautkata]

related thoughts in https://github.com/goharbor/harbor/issues/13276#issuecomment-743769649

[Antiarchitect]

Also SAML

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[metri]

don't close

[timcappalli]

don't close

Why? There is a very high probability that your IdP supports OIDC. Use newer, more robust protocols instead of going backwards.

[brtduvally]

Why? There is a very high probability that your IdP supports OIDC. Use newer, more robust protocols instead of going backwards.

SAML might be older than OIDC but that doesn't mean it's going away or that everything supporting one will support the other. Unless SAML is expected to be deprecated (it's not) or has a small user base (definitely not) it helps to support both.

[timcappalli]

Why? There is a very high probability that your IdP supports OIDC. Use newer, more robust protocols instead of going backwards.

SAML might be older than OIDC but that doesn't mean it's going away or that everything supporting one will support the other. Unless SAML is expected to be deprecated (it's not) or has a small user base (definitely not) it helps to support both.

It does not make sense to prioritize a legacy protocol when there is significant support for its replacement. So yes, I agree, wouldn't hurt to add SAML, but it shouldn't be prioritized when OIDC is already supported.

[teamktown]

While there's OIDC support, SAML access is still desirable in Harbor but maybe it's not a coding story but an integration story. There are many 1000's of SAML only IdPs who have SAML infra but no OIDC infra online right now.

To me there are two main solution pathways; build it in or eternalize the support. Building it in approach:

Rather than do a ground up implementation there may be some work to leverage or gain inspiration from such as Rancher's go SAML work:

• https://github.com/rancher/rancher/tree/master/pkg/auth/providers/saml
• or rely on an external library for the heavier lifting https://github.com/crewjam/saml

Benefit is the full control of how the implementation WRT how Harbor wants to manage identity internally. As well as friends don't let friends write core security code unless they really have to. Drawback is the effort cost of implementation and ongoing support of internal code, docs, testing etc.

Externalizing SAML Support Approach

Harbor could endorse a pattern of a SAML2OIDC proxy in front of it such as SATOSA and repurpose/dual-purpose the pathway of OIDC

Benefit is a more immediate solution via configuration with fewer dependencies and solution is configuration oriented not code oriented, and less obligation on Harbor as a project Drawbacks are the expanding the moving parts in a different way to external dependencies and possibly requiring advanced knowledge of proxying and maybe some attribute translation business during proxying for important elements.

[timcappalli]

@teamktown I don't think there's a need for Harbor to endorse anything. Identity adapters are a well known entity that are designed to be used without blessing from the application/SP.

Also, if those 1000's of SAML organizations are using Harbor, they should advocate for SAML support. I personally don't think these kind of statistics help the discussion as there is a similar story to be told for any protocol or technology (HTTP vs HTTPs, PEAPv0/EAP-MSCHAPv2 vs EAP-TLS, etc)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fooflington]

While I understand the point about OIDC being available and most SAML IdPs probably supporting OIDC, referring to SAML as a "legacy protocol" doesn't really help the situation - it may not be the newest web-based federated access protocol, but it's very much alive and very much not legacy.

[naitmare01]

+1 for SAML

[limparam]

+1 for SAML

[imurata]

+1 for SAML. AWS SSO can manage SAML-enabled applications. Because of Harbor's lack of SAML support, my customer who loves Harbor are now going to stop using Harbor after migration to AWS.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[brtduvally]

This issues is still relevant.

[teamktown]

This issue is still relevant. There's still a wide array of SAML sites that can benefit.

[mortenbirkelund]

+1 for saml

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[jiscfoo]

Would still really like this…!