ComponentSpace

Forums



Getting IdP UIInfo or Organization data


Getting IdP UIInfo or Organization data

Author
Message
cdimitroulas
cdimitroulas
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 9, Visits: 117
Hello,

We are using MetadataToConfiguration.ImportUrlAsync() to pull all the metadata from federations like UKAMF and OpenAthens. The SamlConfigurations that are returned from this method do not seem to contain any of the data that is typically found in the <mds:UIInfo> or <Organization> nodes in the XML. PartnerIdentityProviderConfiguration.Description seems to always be null as well.

It would be great if we could pull some kind of display name for the Identity Providers when using MetadataToConfiguration.ImportUrlAsync(). Is this supported by ComponentSpace?

Thank you,
Christos
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9.6K
Hi Christos,

I'm afraid not. We don't look at these nodes in the metadata. However, this is something we might add in a future release. In the meantime, you would have to add this information as the description yourself. 

Regards
ComponentSpace Development
cdimitroulas
cdimitroulas
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 9, Visits: 117
ComponentSpace - 2/11/2022
Hi Christos,

I'm afraid not. We don't look at these nodes in the metadata. However, this is something we might add in a future release. In the meantime, you would have to add this information as the description yourself. 

Thank you for your response.

I had another question, this time about the SSO result that is returned by the ReceiveSsoAsync() method. There is a UserID field on the object which is returned, however when testing against some test IdPs I notice that the value for this UserID is always different, even if I log in with the same user.

Can you explain what the best way to get a unique identifier for the logged in user would be? We could use the eduPersonTargetedID attribute but I don't think this is guaranteed to be provided by every IdP.

Regards,
Christos
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9.6K
The UserID field is the SAML subject name identifier from the SAML assertion. It's the primary user identity information and, in theory, should uniquely identify the user.

What's returned in the SAML subject and any SAML attributes is controlled by the identity provider. However, typically the service provider negotiates with the identity provider what information should be returned as the SAML subject and SAML attributes.

A commonly used value for the SAML subject is the user's email address.

However, anything can be used that makes sense to the identity provider and service provider.

If you did decide on something like the user's email address, ideally you would ask all identity providers to return this as the SAML subject.

If you picked some other user attribute that isn't common across all identity providers, you might need to do a little more work in your application to handle the different types of user identity information from the different identity providers.

Regards
ComponentSpace Development
cdimitroulas
cdimitroulas
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 9, Visits: 117
ComponentSpace - 2/17/2022
The UserID field is the SAML subject name identifier from the SAML assertion. It's the primary user identity information and, in theory, should uniquely identify the user.

What's returned in the SAML subject and any SAML attributes is controlled by the identity provider. However, typically the service provider negotiates with the identity provider what information should be returned as the SAML subject and SAML attributes.

A commonly used value for the SAML subject is the user's email address.

However, anything can be used that makes sense to the identity provider and service provider.

If you did decide on something like the user's email address, ideally you would ask all identity providers to return this as the SAML subject.

If you picked some other user attribute that isn't common across all identity providers, you might need to do a little more work in your application to handle the different types of user identity information from the different identity providers.

I'm looking at a SAML response received from the test IDP with entity ID https://test-idp.ukfederation.org.uk/idp/shibboleth and comparing it with what ComponentSpace is picking up for the UserID.

As you say, ComponentSpace is using the subject name identifier, but in this SAML response that ID is a transient NameID instead of a persistent one (urn:oasis:names:tc:SAML:2.0:nameid-format:transient instead of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent). I would expect the eduPersonTargetedID attribute to take precedence over a transient ID otherwise we cannot identify these users over time as their subject name identifier will change.

Do we need to ignore the UserID property and look inside the Attributes ourselves in this case? It seems odd that the library doesn't handle this use-case so I feel like I'm misunderstanding something.
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9.6K
These types of precedence rules would be specific to your use case. We simply return the Name ID (ie UserID) and SAML attributes. The application is responsible for using this information however makes sense to it.

We do have configurable mapping rules as described in the Configuration Guide. You could add a rule that maps the eduPersonTargetedID attribute to the UserID. That way the application would access the UserID which would have the eduPersonTargetedID attribute value rather than the transient ID.




Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search