Thanks for the quick response!
I'm aware that I could have made sensitive information containing PID exposed to all users with access to the feed, but that is inappropriate within my organization.
Best regards
Nils Nilsson
Thanks for the quick response!
I'm aware that I could have made sensitive information containing PID exposed to all users with access to the feed, but that is inappropriate within my organization.
Best regards
Nils Nilsson
Hi
I have assigned a group the 'Manage Feed' task permission for a feed group.
However when my user tries viewing the [Usage & Statistics] page for a package within one of the feeds belonging to the Feed Group, they are denied due to lacking Admin_ManageFeed privilege.
Auditing user privileges for the feed and/or feed group does return that they do indeed possess the Admin_ManageFeed privilege.
Most other privileges that are connected to the 'Manage Feed' role do work as expected.
If I instead assign 'Manage Feed' for all feeds they can view the page as expected.
I'm using an enterprise ProGet license and version 2025.11
Hi @rhessinger
Thanks for telling me about the debug endpoint, would have been nice if debug options was made visible in the documentation, since there is already a header for troubleshooting -> https://docs.inedo.com/docs/installation/saml-authentication/various-saml-overview#troubleshooting.
Using the debug output we managed to figure out our issue and get it working.
In our case NameID was being sent as an attribute instead of being part of the subject, resolving that fixed our issue.
<AttributeStatement>
<Attribute Name="NameID">
<AttributeValue>User ID</AttributeValue>
</Attribute>
</AttributeStatement>
changed to
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">User ID</NameID>
</Subject>
Other information omitted for privacy.
Thank you for your assistance in resolving this.
Regards
Nils
Hi @rhessinger
Thanks for rectifying the missing callback URL.
Unfortunately it made no difference for our case as that was already the URL we were using.
We made sure to verify that NameID is being sent in the claim without domain prefix.
All other settings in our ADFS configuration looks as we would expect for a normal SAML integration.
Currently any attempt att signing in using Single Sign-On returns this error: "ERROR: Object reference not set to an instance of an object."
Regards,
Nils
Hello.
My organisation is attempting to configure SAML with our Microsoft Active Directory.
We find that the documentation is lacking for this usecase and, even taking inspiration from the pages for AzureAD(EntraID) and PingID, could not produce a working integration.
Primarily I haven't found any documentation that specify the callback urls for logon/logout.
Thanks you for your advice,
Nils Nilsson