ProGet SAML group mapping

proget+markus.koban_7308

As you may know, Keycloak has the capability to send various groups/attributes during the login process, a feature utilized by numerous other applications to assign users to specific groups.

I was wondering if there are plans for implementing SAML group mapping in ProGet in the future?

stevedennis

Hi @proget-markus-koban_7308 ,

It's highly unlikely we would consider implementing anything Keycloak-specific, but if it's something that SAML supports - and something done by the major providers like Azure, Ping ID, Okta, etc -- we definitely consider it. We just don't know much about it.

We haven't done any further research since that post and we likely won't do any further research on our own, since only one user asked in a few years (and they ended up not needing it anyway).

If this is something you'd be interested in exploring, it'd be best to collaborate and help us bridge the gap between SAML and ProGet.

Here's some relevant questions/discussion from that topic:

I'm not so familiar with SAML behind the scenes... do you know how "SAML group claims" work? For example...

Is it something that comes back in the XML response, or does it require a separate request?

What do the "group claims" look like? Like a list of human-readable group names?

And them most importantly... what should ProGet do with such claims upon receipt? Treat the user as if they're in the group (kind of like LDAP groups), and allow permissions to be assigned against that group (like LDAp, but without searching)?

The hardest part is going to be figuring out how to set this up in a SAML provider, document it, etc.

Thanks,
Steve

proget+markus.koban_7308

I think its Called "SAML Attribut-Assertion" and its a Saml protocol thing, so all saml Providers use it:

Attribute assertions in a SAML (Security Assertion Markup Language) authentication response serve to provide additional information about the authenticated user. Here's how they work:

Authentication Request: A service provider (SP) sends a request to an identity provider (IdP) to authenticate a user.
Authentication Response: Upon successful authentication of the user, the identity provider sends an authentication response back to the service provider. This response typically contains one or more assertions, which are pieces of information about the user. One of these assertions is the attribute assertion.
Attribute Assertions: Attribute assertions contain specific attributes or properties of the authenticated user. These attributes can include various pieces of information such as username, email address, roles, permissions, or group memberships. Each assertion can contain multiple attributes.
Structure of an Attribute Assertion: An attribute assertion consists of a set of attributes represented as name-value pairs. For example, an attribute assertion might contain a user's group memberships as follows:

<AttributeStatement>
    <Attribute Name="GroupMembership" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <AttributeValue>Group1</AttributeValue>
        <AttributeValue>Group2</AttributeValue>
    </Attribute>
</AttributeStatement>

In this example, the attribute assertion indicates that the authenticated user is a member of the "Group1" and "Group2" groups.

Use of Attributes by the Service Provider: Upon receiving the attribute assertions, the service provider can use the contained attributes to make decisions such as granting access rights or providing specific functionalities. In our example, the service provider might decide which resources the user can access based on their group memberships.
Overall, attribute assertions in the authentication response provide a flexible and extensible means of conveying additional information about the user, which can be crucial for service provisioning and enforcement of access policies.

atripp

Thanks for the detailed information @proget-markus-koban_7308 !

So I gather that "Group1" and "Group2" could be built-in ProGet groups that you would create ahead of time. So I think this would then simplify permissions and have to set up fewer users.

This is probably something easy enough to experiment with in a maintenance release down the line. However it's really specific so we'd put this in the category of a Enterprise-customer feature request, and something that we would do in collaboration with a customer.

So best to talk with your account manager on getting this process started :)

Cheers,
Alana

proget+markus.koban_7308

Thank you very much for the information, we will get in touch with our account manager.
We would greatly appreciate having this implemented as we need to manage over 150 users via SAML authentication.