OAuth error when using Okta Authentication in ionic app - authentication

I am getting following error when integrating okta authentication in my application.
OAuthError
{
name: “OAuthError”,
message: “The ‘{0}’ system claim could not be evaluated.”,
errorCode: “server_error”,
errorSummary: “The ‘{0}’ system claim could not be evaluated.”}
errorCode:"server_error"
errorSummary:"The ‘{0}’ system claim could not be evaluated."
message:"The ‘{0}’ system claim could not be evaluated."
name:“OAuthError”
}
Please help me.

+1 with Assil
Error Code is
"The 'sub' system claim could not be evaluated."
By Default the Usernames, even the Users are Assigned to Applications is Blank. And we have to add them manually.
I am checking if that can be done Programatically to avoid manual interventions, will share here.
Add Username
Edit Username

I received the same error using the OpenID Connect sign on method for a custom application. In my case, the fix was to make sure the username attribute was properly set on the assigned application for the user in question.

The message was
"The 'sub' system claim could not be evaluated."
The resolution was as Cayce said. The application if assigned to a user, then that username must appear in the username attribute of the registered application.

Related

Access is denied for the user assigned to group instead of direct assignment to app

I have an application defined in Okta. Both app and users are assigned to the group, yet when user tries to login he gets access denied: Message contains error: 'access_denied', error_description: 'User is not assigned to the client application.'
When user is assigned to app directly, then it can sign in. But should not it work with the group?
Yes, it should work regardless. Are you able to see the application in the list of assigned for your user, when you check in Okta UI? Maybe the group is large, so it takes time, when you assign a large group to the app. Or when a group is assigned to a lot of apps. But in the end you should be able to see the app in question in the list of apps. If it's the case, then something wrong is happening here. Might worth open a ticket with Okta Support. If you don't see the app there, then you do something wrong

Building Custom Authentication Method for ADFS 2019 (v4)

I am having trouble creating a custom authenticator for ADFS v4 on Windows Server 2019. My goal is to create a custom primary authenticator but right now I'd settle for getting a custom authenticator to work as an additional authentication provider. I followed this article by Microsoft and although it states the tutorial is for 2012, it's supposed to work for 2019 as well. I apologize if what follows comes across as a stream-of-consciousness but I'm fairly new to this and may have multiple things wrong with my implementation.
Initial struggles
When I follow the directions from Microsoft, I'm able to see the authenticator in the list of primary authenticators and select it. However, when I go through my authentication process the code never fires. I am never presented with the custom HTML fragment in the project. If I understand the code from this example correctly, I should be able to set the authenticator as primary and only get the HTML from my authenticator. The best I am able to do is get the friendly name to show up in a list of possible authenticators if more than one primary authenticator is selected.
/// Returns a Dictionary containing the set of localized friendly names of the provider, indexed by lcid.
/// These Friendly Names are displayed in the "choice page" offered to the user when there is more than
/// one secondary authentication provider available.
public Dictionary<int, string> FriendlyNames
{
get
{
Dictionary<int, string> _friendlyNames = new Dictionary<int, string>();
_friendlyNames.Add(new CultureInfo("en-us").LCID, "Matt's Friendly name in the Meatadata Class");
_friendlyNames.Add(new CultureInfo("fr").LCID, "Friendly name translated to fr locale");
return _friendlyNames;
}
}
If I click my custom authenticator it just errors and I get an entry in the ADFS event log that says it cannot find the specified user. I thought that by using the custom it would bypass any Active Directory lookup but apparently it's still doing the lookup and I'm never presented with my custom login page.
Then I added logging
I logged every method in my code to the Windows event log and for a little bit I would get a message that the program entered the OnAuthenticationPipelineLoad method.
public void OnAuthenticationPipelineLoad(IAuthenticationMethodConfigData configData)
{
//this is where AD FS passes us the config data, if such data was supplied at registration of the adapter
myNewLog.WriteEntry("Matt -> this is where AD FS passes us the config data, if such data was supplied at registration of the adapter");
}
Unfortunately, this stopped working at some point and I can't get it back so it's like the code isn't even making it to here any more.
Microsoft's example doesn't even work
I scrounged GitHub looking for other people who had done this and found Microsoft's example provider. Unfortunately, Microsoft's code doesn't work either so it must be something that I have configured wrong but I don't know where to look.
Then I tried making it the secondary authenticator
I tried setting my custom authenticator as secondary but the code never fires in this case either.
Suspicions
Before my logging stopped working, I thought the code might have an issue with the AuthenticationMethods metadata.
/// Returns an array of strings containing URIs indicating the set of authentication methods implemented by the adapter
/// AD FS requires that, if authentication is successful, the method actually employed will be returned by the
/// final call to TryEndAuthentication(). If no authentication method is returned, or the method returned is not
/// one of the methods listed in this property, the authentication attempt will fail.
public virtual string[] AuthenticationMethods
{
get {
myNewLog.WriteEntry("Matt -> AuthenticationMethods");
return new[] { "https://example.com/myauthenticationmethod1" }; }
}
I found hints that this could be an issue here and here. It says "IAuthenticationAdapterMetadata: defines adapter metadata including its name and the type(s) of authentication it supports" and "Both the Global and Relying Party MFA AdditionalAuthenticationRules claim rule sets are executed. (Box C). If the output claim set of either rule set contains a claim of type "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod" and value "http://schemas.microsoft.com/claims/multipleauthn", then MFA will engage."
Question
I guess I don't know what I should even ask as my question. Has anyone created a custom ADFS authenticator before and seen this problem? Is there something obvious that I can check that could be causing this?
This turned out to be a two-part problem and was party caused by my lack of domain knowledge.
Secondary authenticator fix
My issues with using my code as a secondary authenticator had to do with setting the claims rules. This is the power shell script that the tutorial had me run:
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'
My problem was that I was testing from inside my network as opposed to outside my network so the script was wrong for me. Once I edited the rule to force MFA for internal users, my code successfully hit.
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "true"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'
Primary authenticator fix
As it turns out, I cannot use my code as a primary authenticator in the way I was trying to. ADFS only allows you to authenticate against the AD identity provider. The message "cannot find the specified user" in the ADFS event log was a result of trying to bypass the step that sets the user. Since I did not want to query Active Directory for my user, I would then get an error that the authenticator could not find the specified user...makes sense.
What I actually needed was a different identity provider. For my relying party trust in ADFS, I needed to specify an identity provider other than Active Directory. I found an example of this here. This solution uses identity server 3 hosted in an asp.net site as an identity provider. By using this solution, I was able to manually set the claims for the current user.
This solution uses identity server 3 which is outdated and ideally you would use the currently supported identity server 4. However, the ws-federation part of identity server 4 has moved behind a pay wall.
I still had a problem with my relying party trust since they would be presented with multiple identity providers (or claims providers as ADFS calls them) when users came to our site from the relying party. To prevent this screen from showing up, you can set your identity server as the default claims provider for your relying party.
Set-AdfsRelyingPartyTrust -TargetName "Relying Party" -ClaimsProviderName ("IdentityServer")
Additional notes
There is a good write on what identity server is and the problem it is trying to solve here
There is also an open source repo for filling in the ws-federation piece of identity server 4 here which I did not use

Restricting Azure Identity Providers

I have set up authentication for my application using the Azure Rest API / OAuth 2 flow, following the steps outlined here:
https://ahmetalpbalkan.com/blog/azure-rest-api-with-oauth2/
I have created an ActiveDirectory application within Azure which is linked to an ActiveDirectory instance.
Inside my own application I have configured it to post to the following Azure OAuth endpoint:
https://login.windows.net/<<MY-AD-TENANT-ID>>/oauth2/authorize?client_id=<<GUID>>&response_type=code
This all works fine. I can authenticate against my ActiveDirectory using emails of the form
someuser#<myDomain>.com
However, I have realised that I can also authenticate using any valid microsoft email address, which obviously means that anyone with a valid microsoft email can get an access token for my application e.g.
randomUser#hotmail.com
Can anyone tell me how I can restrict the authentication to just allow users who are in my Active directory? Users with emails of the form
someuser#<myDomain>.com
I have looked through the documentation but have had no luck so far.
Mechanics of Token Validation
What does that really mean: to validate a token? It boils down to three things, really:
Verify that it is well-formed
Verify that it is coming from the intended authority
Verify that it is meant for the current application
Your problem is that you are not doing the number 3 validation.
You probably are missing something like this in your application where you are validating the token:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
});
Currently I have the same problem and trying to figure out a solution.
That's what I found out:
After authentication you get back a JSON Web Token (see this page https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). After decoding this, there are several information available. But I am not sure which of those could possibly make sure to only allow login of the specified Active Directory.
#Aram refers to the values audience (aud) and tenant (tid). Unfortunately audience is always set to the app_id given with the request and tenant is always set to the tenant-id of the Azure tenant, although you are using a live.com account, for example.
Finally, I came up with the idea of checking for the existence of oid (»Object identifier (ID) of the user object in Azure AD.«, https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). I hope that this one will only be set if the user is part of the Active Directory that is issuing the authorization.
As a result, I set my app up to do the following: If in the decoded version of the id_token of the Access token response there is no oid property set – the login-request will be rejected.
Problem is: I can't confirm that my approach works, because I don't have a second Azure AD and can't check if only live/hotmail/... users will not be given a oid, but also users from different ADs. Maybe #bobbyr you could try that out and report?
Thanks to Thomas Ebert's prompt I've figured out a way to solve my problem. I don't know if it will help anyone else, but...
Basically when my app gets the token from Azure, before passing it on to the client, I can decode the JWT and just look at the email field.
In my case if the email address isn't one that belongs to my domain I can just send a 401 unauthorized back to the client.
It feels weird that Azure doesn't offer some way of doing this via config, maybe it does, but noone has answered this for me, and I've read enough of their docs now to want to pull my own eyes out so I never see the word Azure again...

Facebook Login without JSSDK, how to get token if already authorized previously

So I am updating an older desktop app (written in VB, .net 4.0) with facebook integration and followed the guide found here, and have been able to successfully get a token (by parsing the uri of the embedded webview if it contains "token="). Now my problem is if I try to login with a facebook account that has already approved the app in a prior session, the webview just gets redirected to https://www.facebook.com/connect/login_success.html without any token information.
Do I HAVE to log all of the tokens I generate manually (ie on successful token generation, I can call their profile info, use their FB ID as key and save the token)? Even if I do, since the email and password is input directly into the facebook login window, how do I check if the user already has a token?
Thanks in advance
The access token can change any time, you need to get it everytime. After getting the token, I immediately get the user information https://graph.facebook.com/me?access_token=??? and use that ID to find their database information.
I couldn't quickly find facebook information but on google's oauth information it says "The access token is also associated with a limited scope that define the kind of data the your client application has access to (for example "Manage your tasks"). An important goal for OAuth 2.0 is to provide secure and convenient access to the protected data, while minimizing the potential impact if an access token is stolen."
https://code.google.com/p/google-api-php-client/wiki/OAuth2
Ok so I finally figured it out myself. My mistake was apparently requesting the access_token directly (ie https://www.facebook.com/dialog/oauth?response_type=token...) to try and save time.
I fixed it by making a request for a 'code' instead (ie https://www.facebook.com/dialog/oauth?response_type=code), which I then use to make a second request to retrieve an access token as documented here: https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/, "Exchanging code for an access token" section a bit lower on the page.
Hope this helps someone in the future, this was very frustrating on my part.
Regards,
Prince

Claims not being passed to a Relying Party in ADFS 2.0

OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.