Posts made by jblaine_9526

Nope, that's my bad.
I was just going off of the documentation here: https://docs.inedo.com/docs/various-saml-overview?highlight=saml
under the Technical Limitations section that says:
"At this time, role-based permissions are not automatically resolved from the identity provider, and must be configured within the Inedo product itself under the associated directory provider, and may require adding users to groups in the Inedo product for granular permissions"

I just assumed that this was on the roadmap to be done since it was listed on the documentation.

Sorry about that....

That being said, being able to use SAML group/role claims would be wonderful! :)

Hi, I'm just wondering what the status is on supporting group claims from a SAML auth connection.
Is this available in 2022 or is it still in the works ?

With the new multiple user directories option, I'm unable to use to the SAML Users and Groups tab of the security configuration to identify SAML Users and Groups.

I've configured multiple directories (Active Directory and a SAML directory) and the SAML Users and Groups tab shows up when i enable the SAML directory, however I get a 500 error page when I click on the tab.

The error that shows up in the logs is this:

 Logged:
6/24/2022 4:01:01 PM
Level:
Error
Category:
Web
Message:
An error occurred in the web application: Unable to load the specified user directory
Details:
URL: https://proget/administration/security/external/users?userDirectoryId=4
Referrer: https://proget/administration/security/manage-directories61
User: <admin user>
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Stack trace: at Inedo.ProGet.WebApplication.Pages.Administration.Security.SecurityPageBase.CreateChildControls()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePageBase.<InitializeAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Inedo.Web.PageFree.SimplePageBase.<ExecutePageLifeCycleAsync>d__57.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Inedo.Web.PageFree.SimplePageBase.<ProcessRequestAsync>d__56.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
at Inedo.Web.Handlers.AsyncHandlerWrapper.EndProcessRequest(IAsyncResult result)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Note: when I look in the database, the directoryID for my SAML directory is actually 6.

Hi!
Thanks so much for the quick turnaround on the version ranges with upack packages.
I've found a couple of issues with the implementation of PG-2084.

1. It seems to have trouble supporting the upper open range specified on https://docs.inedo.com/docs/upack-universal-packages-manifest; Specifically with the GroupName/PackageName:[x.x.x,] I am getting the following error message (with stack trace). From a quick look at the upack lib implemenation of UniversalPackageVersionRange.TryParse, it appears as though the second version in the range must always be populated though the specification says to leave unpopulated for the latest. (Note * for the latest doesn't work either.)
   This is the full json kvp for this error
   "dependencies": ["groupname/packagename:[8.0.0,]"],

An error occurred in the web application: Invalid version range specification.
Details:
URL: http://localhost:8624/feeds/test/GROUPNAME/PACKAGENAME/8.0.10/dependencies
Referrer: https://localhost:8624/feeds/test/GROUPNAME/PACKAGENAME/8.0.10
User: Admin
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Stack trace: at Inedo.UPack.UniversalPackageVersionRange.Parse(String s)
at Inedo.UPack.UniversalPackageDependency.Parse(String s)
at Inedo.ProGet.Feeds.Universal.UniversalPackageVersionInfo.ReadDependencies()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at Inedo.ProGet.Feeds.Universal.CommonUniversalPackageInfo.<GetDependenciesAsync>d__20.MoveNext()

2. When clicking the link to the dependency, the link defaults to the beginning package that satisfies the range, however I would expect it to take the user to the latest package that satisfies the range. Note: this behavior also applies to the non-inclusive lower bound. I.e., the dependency link links to a package that is not actually within the range. groupname/packagename:(1.0.0,1.1.1] will link to groupname/packagename:1.0.0 but should link to groupname/packagename:1.1.1.

@atripp Sounds good to me I have no problem with you sharing my email.
In the meantime I've updated our tooling to use solely APIKeys with SAML enabled in order to get what I need for my current POC testing.

@atripp Just as a clarification, this would allow both SAML SSO, and local user authentication?
Currently with SAML enabled, there is no way to bypass the SAML authentication on login. Would this enable an option to bypass the SAML authentication in order to log into the server?

Hi,
I'm looking into setting up SAML authentication as a primary means of login to Proget, however when I am connecting programmatically to the API I still need to be able to connect with local user authentication because I'm not able to use API keys and this fails.
Is there any plans to allow a hybrid SAML and local auth database?