Skip to content

FDS Gateway Login Connector documentation - #11691

Open
Karuna-Mendix wants to merge 6 commits into
developmentfrom
kv-sam
Open

FDS Gateway Login Connector documentation#11691
Karuna-Mendix wants to merge 6 commits into
developmentfrom
kv-sam

Conversation

@Karuna-Mendix

Copy link
Copy Markdown
Collaborator

No description provided.


The [FDS Gateway Login Connector](placeholder) enables Single Sign-On (SSO) for Siemens products by integrating Mendix applications with Siemens Foundational Services (FDS).

Instead of authenticating users directly, the connector delegates authentication to the FDS Gateway, the shared identity platform for Siemens Xcelerator products. Depending on the customer's FDS configuration, users can sign in using either their Siemens ID or their organization's workforce identity provider, such as Microsoft Entra ID. This provides a consistent, secure authentication experience and allows organizations to continue using their existing identity and access management (IAM) infrastructure.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't call the FDS Gateway "the shared identity platform for Simens Xcelerator products". It's not wrong but also not right.
Instead i would suggest:

"a shared access layer for Siemens Xcelerator applications and services that integrates with FDS IAM."

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm doing some thinking and would also like to add a sentence that refers to OIDC.

  • if we use the same introduction in the marketplace, it will give a hit for users seraching OIDC, which I think is good.
  • it also explains the value of the module. So not only WHAT it's doing but also explianing WHY that is relevant.

I suggest to add: "The connector abstracts the underlying OpenID Connect (OIDC) integration with Siemens Foundational Services, reducing the need for application-specific identity provider configuration."

Instead of authenticating users directly, the connector delegates authentication to the FDS Gateway, the shared identity platform for Siemens Xcelerator products. Depending on the customer's FDS configuration, users can sign in using either their Siemens ID or their organization's workforce identity provider, such as Microsoft Entra ID. This provides a consistent, secure authentication experience and allows organizations to continue using their existing identity and access management (IAM) infrastructure.

The connector supports federated authentication by relying on the identity relationships configured in FDS, enabling Mendix applications to integrate seamlessly with the Siemens Xcelerator ecosystem.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel this sentence is repeating what previous introduction already says. It feels a bit more fluffy as well. Let's remove

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify for whom this connector is aimed, i suggest to add:

"This connector is intended for Siemens Xcelerator products and other applications that are required to authenticate users through Siemens Foundational Services."

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also i would want to add the following:

"Terminology note: Earlier discussions and documentation may refer to Siemens Access Management (SAM) or SAMv2. The current Siemens Foundational Services terminology uses FDS IAM and FDS Gateway."

Two reasons:

  • it will make the module discoverable for users looking for SAM
  • it will also explain situation for users who may ask "ok, so is this the SAM module?"

### Typical Usage Scenarios

* Build an Xcelerator product with Mendix. End-users sign in through Siemens FDS IAM, with the FDS Gateway handling authentication and providing tokens to your application.
* Build single-tenant products for contracted customers, or multi-tenant products for prospective customers to evaluate before purchase.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of typical usage scenarios, I think we can formulate more clearly. I explianed to copliot the intend behind the draft and it suggested:

"* Build a Siemens Xcelerator product with Mendix that must authenticate users through Siemens Foundational Services (FDS).

  • Build single-tenant deployments for contracted customers or multi-tenant evaluation environments for prospective customers, while using Siemens Foundational Services for user authentication."

I think that explains better. Agree?


* **Login session initiation** – After the FDS Gateway authenticates the end-user through FDS IAM, the connector initiates a local session in the Mendix application. The application does not display its own login page, providing a seamless SSO experience.

* **Just-in-time user provisioning** – When a user signs in for the first time, the connector automatically creates a corresponding user account in the Mendix application based on the JWT claims received. You can use the default provisioning logic or implement custom provisioning. On subsequent sign-ins, the connector can also update user information using the same provisioning logic.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can make even clearer by adding:

"The connector does not require pre-provisioning of users into your app"


* **Role-based access control** – User roles are assigned dynamically based on claims in the JWT tokens received from FDS, enabling centralized authorization management.

* **Tenancy support** – The connector makes a tenant identifier available when a user signs in. Your application can use this identifier to ensure users can only access data for their own tenant. The connector provides the tenant information; you are responsible for implementing the tenancy structure.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm doing AI assisted review, i agree with copliot that a sentnece like the following makes it more clear what we do / don't do. The connector enables tenancy. It doesn't implement tenancy.

"The connector exposes tenant information supplied by FDS. Your application is responsible for implementing tenant isolation, data partitioning, and authorization logic."


#### Limitations

* **No synchronized session management** – Authentication is delegated to the FDS Gateway, but session management is handled independently by the Mendix application. Changes to a user's login state in FDS Gateway are not propagated to active Mendix sessions, and FDS-initiated logout is not supported.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's chnage the title from "No synchronized session management" to "Independent session management".

This makes it sound less as a misisng feature. This is important because it may not be easy to synchronize sessions even if we'd want to.


For more information, see [Constants](/refguide/constants/).

## Enabling Single Sign-On {#sso}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this title is a bit over-promising.
Maybe better to say: "Configuring the SSO Redirect" as a section heading?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants