ucarion

Yeah, we have this -- if you check out the docs for the endpoint where you accept a SAML login[1], there's an `attributes` (map<string, string>) that SSOReady returns to you. That contains the contents of the relevant SAML assertion's AttributeStatement.

So if you're familiar with Okta's parlance, both "Attribute Statements" and "Group Attribute Statements" are returned to you in `attributes`.

[1]: https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...

The interface between your app and SSOReady is entirely over an HTTP API. We codegen SDKs for that HTTP API for Python and TypeScript, and will add more, but in the meantime the docs show you the curl you'd need to port:

https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...

I think the reality is that the category of software we're open-sourcing isn't very big. We're gonna make our money doing other things, not all of which will be open-source.

My personal phone number and email is in the sidebar of app.ssoready.com for this exact reason.

> Question: For the free hosted SSO, how well are you going to be able to secure that, so that your customers aren't compromised through you?

Yeah, this is super important. No short answer here, it's just about doing the work and getting it right.

We're working with Oneleet for our SOC2 stuff (which we all know is largely theater) but also pretty thorough pentesting. I can email you their findings.

The reality is we're one of those companies that need to get this stuff right.

> Question: Will the free tier SSO have uptime guarantees, since it'll be a single point of failure for all your customers? For startups that decide they'd like it hosted for them, but need an SLA, do you expect to be able to provide that at a price doable by startups?

Our plan is to work out agreements on a case-by-case basis. It'd depend on exactly what you need. We take guarantees pretty seriously, so we're careful about what we promise.

We're not a services business. We don't want to make money off of "premium support". There is a modest price tag if you want an SLA.

> (Will a cloud provider pick up those customers using your software?)

Would you mind rephrasing?

I've written one of these 204-page PDFs before (I think it was more like 20 pages though). The IDPs don't exactly make it easy on their customers to set this stuff up, and the burden ends up on the SP (i.e. you) to document to folks how to use their own IDP.

Incidentally we just shipped something for this. Rather than having to make a 204-page PDF, you can go into SSOReady, generate a setup URL, and give it to customers. Customers can visit that URL and they get a self-serve UI for configuring their SAML connection to your product.

https://ssoready.com/docs/idp-configuration/enabling-self-se...

OIDC2 is the better protocol, don't get me wrong. But lots of companies run on SAML, and it's the thing customers explicitly ask for.

Most folks will read that README and conclude SAML isn't going to happen for them today.

Take any language's biggest SAML implementation, and it's the same story of a library with some epic README covering dozens of public methods you may or may not need to use. People can't make heads or tails of this stuff.

Clarity and simplicity are the precursors to security. I'm pretty obsessed with making SAML clear and simple for folks.

Yeah SCIM is coming up. Auto-deprovisioning and stuff related to seat management are the big motivators I've seen.

Honestly IETF did a pretty good job with SCIM itself. It's not wacky in the way SAML is at all. In my experience the hardest part about integrating SCIM is setting up all the IDP-specific configuration around it. Like with SAML, it's a situation where Okta, Microsoft, OneLogin all have totally different terms for the exact same thing.

One thing I'm pretty excited about is that our SCIM support will also include a button where you can generate a setup link that you give to your customer. From that setup link they can self-serve configure their SAML+SCIM configuration.

We have that working for SAML right now, and it's nice because it means you don't need to write IDP-specific documentation walking customers through each product's weird terminology and quirky UI.

It's hard to answer questions like this in the abstract. The details matter.

Agreed. XML Signatures is the worst part of SAML. It's a spec that's basically begging to be done wrong. I remain confused as to what W3C were thinking.

https://ssoready.com/blog/engineering/xml-dsig-is-unfortunat...

Is anyone going around choosing SAML today, though? XML fever has come and gone.

Usually SAML happens because customers ask for it, OIDC isn't as widely implemented by IDPs as SAML is, so you end up implementing SAML and moving on with life.

The US has 400 land-based nuclear weapons, not thousands upon thousands. They're there to be a better thing for our enemies to aim at than our cities.

Lots of these have been popping up lately, they all seem really good. This is the first one I've seen with an answer for "I want to customize the output by hand", which is neat.

https://buildwithfern.com/ https://liblab.com/ https://www.speakeasyapi.dev/

Between this and fancy API doc generators (Mintlify, etc.), I feel like we're finally getting close to being able to just go from OpenAPI to Stripe-level "polish".

I was in the last batch. The average is probably ~28 years old, but there are plenty of founding teams in their 40s and on. Plenty of folks with families. You wouldn't be a dinosaur.

Apply.

Makes sense!

My gut tells me that it would often make sense to jump straight to shuffle sharding, where you'd converge on fair solutions dynamically, in a lot of cases. I'm looking forward to that follow-on article!

This is pretty fancy stuff! Sorry if I'm just not reading carefully enough, but does this approach account for tenants whose messages take longer to process, as opposed to a tenant that sends a larger volume of messages?

Thanks! Yeah, we all stand on the shoulders of the giant that is Tailwind UI :)

Task management, lists/views, and general "journeys" management are all on the roadmap. There's a lot of stuff you need to do to be generally competent in this space, we're definitely launching very early here.

When I talked about Apex, I really mean the "scripting language that sees data mid-transaction" aspect of the language. Sounds like you're not really seeing the value there either? I totally agree that good old webhooks or some other trigger is seems almost always good enough if the API is fast.

Appreciate the suggestions re: comms and consent management. We're still not sure how we want to handle dialers.

Salesforce is where the money is. There's plenty of competitors.

Definitely going to add the hotkeys-for-objects feature! That's on my to-do list.

Want to work on reducing bundle sizes. Just haven't gotten a chance to get to that yet. Totally agree that load times really matter here, I've been focused on that and still have a few ways to speed that up.

Not yet, but we're thinking about it!

These are all great points!

1. Definitely want to improve favicons. For deriving fields, we do have formula fields. Would love to show that to you, it's not obvious enough how to use to enable for this HN launch.

2/3. Sorry about that. This username/password approach for the HN launch is definitely a hack.

4. Right now, search is just on the current type of record you're looking at. I want to fix this, and I just haven't because I haven't made the UI for filtering what objects to search across. The backend is in place though. Glad it seems suspiciously fast! I can assure it's a real FTS talking to a database.

5. I want to fix this too. A way to make data of type "Link" for better UI treatment.

6. Archiving is meant for data that others shouldn't be looking at -- it's a staging ground for data. That's why you can't point into archived data. It's also a precursor for deleting data, and we want to guarantee no dangling references to deleted data.

7. Will fix this.

So far, we've been doing setup on behalf of customers precisely because it's the easiest option for our customers.

We're open to exploring self-serve, but realistically that's going to be really hard to get right. I'm imagining we may have templates that customers can choose from down the line, where they can one-click setup a CRM for their kind of business.

Should be healthy again, sorry!

Yup, that's a good catch. Fix going out now.

You should check out https://www.stacksync.cloud/ (YC W24) -- they do a bidi realtime sync between CRMs and databases. Not sure if that scratches your itch!

We are definitely looking to make our API public. We've built our core data model in such a way that business users can't accidentally break API users by, for example, making backwards-incompatible changes to their objects. It baffles me that everyone else in the space gets this wrong. But still, I want to feel really good about making an API that can stick around a long time before telling people to use it to run their business, and we're just not there yet.

You should check out Twenty! https://twenty.com/ (YC S23) -- they're an OSS CRM.

I totally agree the object management UI is too clunky right now. I want to redo that set of pages, they were the first ones we shipped. Not gonna lie, idk if anyone except me and Ned are really pining to learn hotkeys for managing object schemas, since in practice we're the only ones doing that on a regular basis -- we do initial setup on behalf of our customers.

Yeah, I consider latency part of UX. We're doing some somewhat fancy stuff to reliably replicate every record into a couple of stores, each of which is optimized for different access patterns (search, get latest by ID, etc.). The big central Postgres(TM) is mostly there to be authoritative and to transactionally maintain invariants in the system.

Working on the account lock, sorry. Password stuffing alarm is tripped. EDIT: in the meantime, a jank workaround. Just added a few more users:

hn.login.alt1@okapicrm.com

hn.login.alt2@okapicrm.com

hn.login.alt3@okapicrm.com

All have the same password as in the original post: sk9ueEAfhXP9j4cuxLCVmw7. (include the trailing period)

We rely on GMail or Outlook's spam and checks. We only sync emails that made it to your non-spam inbox.

Totally agree we're way too barebones to say we're an SFDC alternative today. Reports and dashboards/views are the next two things on the roadmap. For workflows we've been using our Zapier app so far, but we're looking to potentially do that built-in. Integrations is going to be a long list of work. Going to feel like working at Segment again. :)

For sourcing and campaigns, our initial plan is a two-way Apollo integration. Not sure if you have thoughts on the necessity of doing everything in-house (the Hubspot approach) or just focusing on integrating with the best tools (the Salesforce approach).

Your feedback on the website is well taken. We've got a lot of work to do there.