We would love to see this implemented in the Future, is there any Chance for this?

Hello Rich,

the issue seems to be that when creating the feed, 2 connectors are being created. One connector has the predefined name, while the other is generated arbitrarily from existing feed names.
Example:
Create Feed > Maven Artifacts> Connect to another Feed> Connect to another Feed>
Connector name: test-connector
Endpoint URL: http://www.dcm4che.org/maven2
Name Feed>
Feed Name: test-feed
Create Feed>

After creating the feed, the following 2 connectors exist:

test-connector
npm-internal (named after another existing feed)
In the event log, you can see that first the correct connector is created, then the feed is created. After that, a second connector is created, which is the only one associated with the feed.

regards
Markus

Hi Rich,
we updated to Version 2023.33 (Build 1) yesterday and we still got the error.

Whenever I try to create a feed on a 3rd party repository using "Create New Feed" -> "Maven Artifacts" -> "Connect to Another Feed," it ends with a 500 error. Although the wizard creates a suitable connector, it doesn't create the feed itself. I have to manually recreate it afterward with "No Connectors (private artifacts only)" and then manually connect it with the connector.
Is this a Bug or expected behaviour?

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.

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.

Re: ProGet SAML group claims

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?