Service Provider - required? (SimpleSAMLphp migration)

It depends on what this means:

if my IdP already provides SAML metadata about using them as a Service Provider,

I'm inclined to assume that this means: your IdP provides SAML metadata which should be used by the Service Provider (i.e. configured at the Service Provider's side). Which, yes, you need to do in Drupal because the Service Provider is integrated into Drupal, and Drupal exposes the configuration screen.

If, instead, you are saying that your IdP provides both a set of IdP metadata and a set of Service Provider metadata, then... I'll need more information.

Because there are defintely always two sides (the IdP and the SP) which are going to exchange information and SAML messages with each other. If both end of the communication line are set up at your IdP, then that would be news to me.

I recently rewrote the module's README.md a bit - it's not included in the latest stable release yet. Maybe you can check the "Stage 1" section a bit, and see if that makes a little more sense. (It has more explicit wording about the "both sides".

Now that I read it again...

if my IdP already provides SAML metadata about using them as a Service Provider,

Maybe they are saying "you can use us as a SAML Idp or as a SAML SP" ?

That's OK, but that's an "either-or", not an "and". If you use them as an SP, then I assume this implies the IdP is on your side. Which is a different use case (that we can ignore here).

Also, maybe I should include a reference to the "SAML login flow" documentation page → in the README; maybe that makes a little clearer, what is happening.

Sorry, I should have read up a bit more before posting. I'll read through these links. In the meantime here is some more info about my question:

My goal is to be able to log into the Drupal site using our IdP. We're currently doing this with simplesamlphp_auth, but we're upgrading to Drupal 10 and need to replace this set up. In practice here is our workflow, from the user's perspective:

1. User goes to /user of the Drupal
2. User clicks a "Federated login" link
3. User is redirected to a separate domain to complete the login process according to the IdP
4. User is redirected back to /user but is now logged in

As mentioned, we're currently doing this with simplesamlphp_auth, and we have the relevant bits from the IdP entered into simplesamlphp configuration files.

My first attempt at migrating to samlauth was to take all of the metadata from our simplesamlphp config files and try to enter it into the samlauth admin form. However all of the stuff under "Service Provider" seems to be new (for us at least).

Maybe this specific question might help me understand - in order to achieve the workflow described above, will I need to create a keypair?

Thanks all for the responses, I really appreciate the support.

Also, I realized that since our repo is public I can point you directly to our simplesamlphp config files, in case this is helpful: https://github.com/usdoj/foia-api/tree/8.1.0/simplesamlphp

We're currently doing this with simplesamlphp_auth, but

Ah. That means I can tune my explanation.

So the SP was SimpleSAMLphp, and then your website was separate. You are migrating to a simpler setup ( some pictures might help → ):
The SP (technically a composer-installed PHP library, for which this Drupal module provides a configuration screen) is now integrated into the Drupal site. So you get rid of the separate SimpleSAMLphp application; Drupal itself replaces it, and there's no 'semi magic' Non-SAML-based communication between the SP (SimpleSAMLphp) and Drupal anymore, because they are the same thing. The Drupal login is immediately done when the SP authenticates the user, in the same HTML request.

However all of the stuff under "Service Provider" seems to be new (for us at least).

The main things shouldn't be new. They are just equivalent to your SimpleSAMLphp config. Currently you have the Entity ID / URLs / public key from SimpleSAMLphp configured at the IdP side; you need to replace that data with the URLs hardcoded by the samlauth module + Entity ID / public key that you configure in the module.

Maybe this specific question might help me understand - in order to achieve the workflow described above, will I need to create a keypair?

Either create a keypair and replace that public key in your current IdP config... or configure the current keypair that you are using in SimpleSAMLphp, in the samlauth module.

By the way, now your initial message sounds to me, as if a third party is maintaining SimpleSAMLphp for you.

That configuration isn't supported. This module does SAML communication; it does not do the "magic non-SAML backchannel communication" that is happening between SimpleSAMLphp and the Drupal site / simplesamlphp_auth module.

Blah. If I read your message again, you already know all I was saying about replacing simpesamlphp. If that is the case, here's a different answer:

My first attempt at migrating to samlauth was to take all of the metadata from our simplesamlphp config files and try to enter it into the samlauth admin form. However all of the stuff under "Service Provider" seems to be new (for us at least).

Some of the main things may seem new but aren't really:

• This module has hardcoded URLs. SimpleSAMLphp had hardcoded URLs. These should just be replaced on the IdP's side.
• In this module you need to configure an Entity ID. SimpleSAMLphp also has an Entity ID, I swear. So this isn't technically new. But maybe it was hardcoded in SimpleSAMLphp so you didn't notice it. (You have it configured on the Idp's side. Probably the Entity ID has the form of a URL like "http://simplesaml.domain/auth.php/blah". Technically, though, it's just a string value so you can keep it the same if you want. As long as the Drupal SP and your IdP have the same value configured.
• This module needs a keypair. SimpleSAMLphp needed a keypair. Same thing. You can either keep using the same, if you want - or make a new one and replace the public key on the Idp side.
• The rest of the samlauth "SP settings" are miscellaneous, and few. From the top of my head: just some caching options.

Thank you for all the clarification! I think my biggest missing link was the fact that simplesamlphp was actually a Service Provider. Also, I had no idea that simplesamlphp had a key/certificate. Anyway, thanks again, I will mark this as resolved.

Automatically closed - issue fixed for 2 weeks with no activity.