How to Handle Additional SAML Assertions?

I've been using Wt::Auth::Saml::Service to provide Azure AD SAML SSO successfully for a while now. My assertionToIdentity function looks like this:

Wt::Auth::Identity Service::assertionToIdentity(
  Wt::Auth::Saml::Assertion const& assertion) const
{
  // Convert the assertions returned from Azure AD into an identity. Return a
  // default constructed identity if anything goes wrong.

  auto const* displayName = assertion.attributeValue("displayName");
  auto const* emailAddress = assertion.attributeValue("emailAddress");

  if (assertion.subject && emailAddress && displayName) {
    return Wt::Auth::Identity(
      name(), assertion.subject->id, *displayName, *emailAddress, true);
  } else {
    return {};
  }
}

Now I need to add roles to my web application. I added "user.assignedroles" to the claims returned by Azure AD SSO. And I can get the assigned roles from the assertion:

  auto const* role = assertion.attributeValue("role");

But what do I do with the role? There doesn't seem to be any room in the Wt::Auth::Identity class for role or arbitrary claims beyond name and email, and I can't inherit from Wt::Auth::Identity because it is returned by value and passed by value to the authenticated signal.

What's the best approach to allow me to integrate roles in my web application?

Replies (3)

RE: How to Handle Additional SAML Assertions? - Added by Roel Standaert about 1 year ago

I think the API wasn't set up for that at the moment. It would be possible, but you'd
have to save that information in the assertionToIdentity function, and then later associate it with the right user in your user database.

RE: How to Handle Additional SAML Assertions? - Added by Aaron Wright about 1 year ago

What about adding a dictionary to the Wt::Auth::Identity class so that it can save all of the claims and various information about a user, such as the id, name, email, verified email, role, etc., instead of a hardcoded members?

I don't actually use a user database. I found the whole user database, widgets, popups, registrations, and most of the authentication tutorial very overwhelming. All I'm looking for is Azure AD SAML SSO. So, I ended up using just the Wt::Auth::Saml::Service for configuration, the createProcess function to get a Wt::Auth::Saml::Process instance, and the authenticated signal and startAuthenticate functions of that instance. It took a while to figure out how to use the classes, but they have been rock solid for a year now.

I might just try to patch Wt::Auth::Identity to support what I need and see where that gets me. It's a pretty simple class.

RE: How to Handle Additional SAML Assertions? - Added by Roel Standaert about 1 year ago

I don't actually use a user database. I found the whole user database, widgets, popups, registrations, and most of the authentication tutorial very overwhelming.

Fair enough :-)

Extending the Identity to add arbitrary attribute/value pairs could be a possible solution, yes.

(1-3/3)

Project

General

Profile

Wt