Access claims in .NET C#?

Ok, got not responses on this post. So let me ask differently.

We are using the Okta Sign-in Widget on a .NET aspx page.

The code for this page is here (sanitized). Our goal is to retrieve the authorized user name from the claims array within the Page_Load() event of the form. Is this even possible?

Thanks for any help in advance.

1 Like

A couple of questions for you:

  • Is this ASP .NET Web Forms? (I assume so)
  • Which version of .NET Framework are you targeting?
  • Is building a custom sign-in page a hard requirement, or would you be able to redirect to an Okta-hosted sign-in page?

Simply placing the Sign-in Widget on the page is tempting, but it won’t quite work because ASP .NET is picky about how you sign users in. Unless you hook into the ASP .NET authentication mechanism, it won’t be aware of the user.

We are working on a sample to demonstrate how to do this right now. We can definitely help get this working. :slight_smile: Let me know the answers to my questions above.

@nate.barbettini, thanks for the reply! Let me answer your questions and then give you some background.

  • Is this ASP .NET Web Forms? (I assume so)


  • Which version of .NET Framework are you targeting?

4.5.2 or higher

  • Is building a custom sign-in page a hard requirement, or would you be able to redirect to an Okta-hosted sign-in page?

custom page is not a hard requirement. Here’s where I think some background will help.

We use a product (Qlikview QV) which we want to authenticate through Okta. However, QV does not have the ability to work with Okta, so they provide an example on how to custom authenticate with another provider using a stand-alone aspx page. The sample just illustrates how to authenticate with the 3rd-party provider, not specifically Okta. QV provides a .NET API that is used to populate what QV needs to authenticate.

So our needs is two-fold

  1. Extract the login name (username) from Okta after authentication, and populate the QV packet using its .NET API.

  2. Make sure whatever token is needed is passed along so that if the user leaves QV to anther site, SSO is enabled.

Here’s a link to the sample Authenticate.aspx page provided by QV. Again, this is just a sample. The idea would be to replace the content of the authUserAndGetGroups() method to retrieve only the user in our case from Okta after authentication. This could very well be the hosted Okta page.

Hope this helps in determining what we need to do.

I should state, if we could do this all within the Authenticate.aspx page, that would be great. I guess, however, that it would be possible to do this all within a .NET app similar to the startup projects on the Okta site.

Thanks for your help.
— x

Hi @nate.barbettini, I was just wondering if you had any further comments on this.
– x

Ah, I understand. You need to add Okta SSO to an app that doesn’t support a standard SSO protocol. (I assume QV doesn’t support SAML?) Are your users internal employees of your company?

I want to make sure I understand this part:

Do you mean SSO to other Okta-enabled applications? In other words, keep the user signed into Okta so they can access their Okta dashboard, other Okta apps, etc. Is that right?

There are two ways you can achieve this:

  1. Do it all through your Authenticate.aspx page, by using the Authentication API to verify the user’s login and password. You will need to write HTTP code to talk to the Authentication API yourself (we’re working on an SDK). After you receive a response containing the user’s id, you could then use our .NET SDK to query the user’s groups. Note that this approach does not start an SSO session for the user, so they will not be logged into Okta or other apps.
  2. Build a small app with our ASP.NET middleware instead that redirects to the Okta-hosted login page and then back to the app with an ID token. The ID token will contain the user’s info, and you can customize it to include groups as well. Then pass that info to the QV SDK and redirect to QV. The user will have an Okta SSO session in their browser.

Let me know if that makes sense!

@nate.barbettini, You answered this several months ago, then I got redirected to another project. Well, I’m back on this now and have decided that #2 is the best option to me. My steps are as follows:

  1. User goes to QV page, page determines if user is authenticated. If not, redirects user to Auth page (Auth page is the small app you suggested building.).

  2. Auth page authenticates user with the Octa-hosted login. Auth page saves the username and groups in the header.

  3. Auth page redirects user back to OV page with data (including ID token from Okta).

So, my follow up questions are:

  1. For step #1, how (using java script) can I determine user is logged in? I supposed I could use the username in the header, but I’m wondering if there is a more secure/okta way to do this.

  2. in Step #3, how to I forward the ID Token from Okta from the Auth Page back to the QV page so that it gets passed along with every redirect (we’re trying to accomplish SSO after all).

Thanks again Nate, and sorry for the late reply.

— x