I am trying to add the custom Attributes via the SQL, and I'm following the steps on [https://blogs.technet.microsoft.com/vinitt/2013/04/15/how-to-use-to-custom-sql-attribute-store-to-generate-claims-and-authorize-user]
I got the SQL Server setup, with the table 'attributes', but then I get to the step where it talks about the relaying party trust... Just edit the non-existent relaying party trust. (Application is working correctly right now, it is a website using ADFS to provide the Authentication, but not the authorization) - I had code for the API side to query the database and add Claims on the fly, but that only works for the server side code, we really need those claims in the JWT.
So, looking at this article everything looked great. I got the SQL Server, and I just need to add the rule to hit the server once the person's logon is validated.
Sounds like a piece of cake, but there is no where to add the claim rule - as I don't have (or need?) any relaying party trust - this can be handled 100% by the AD FS Server, so no need for any relaying. I tried to add one, but couldn't get past the first question. Guessed on that one, and couldn't get past the 2nd question. At this point I gave up... I doubt that entering random data into the form is going to work.
Can someone tell me how to add this? Please note: this is NOT a sharepoint site, and has nothing to do with Sharepoint. It is a .Net Site running an angular application that redirects to the ADFS Server and gets redirected back with the token..
So, anything wrong with this claim Rule:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "SQL", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT role from dbo.ADFS_attributes where logon={0}", param = c.Value);
Specifically, the attributes table has logon and role, and I'm trying to create roles based on records for that user. (In this case, it should create one per each result (I hope))
I've tried to change this to 'select 'Admin' role' in order to just always return a role to use, but that doesn't work either. I don't see any errors in the event log, just nothing... no change to the JWT that comes back.. (Still the same number of claims) - I can't even seem to add 'email' as a pass through claim, so I'm missing something here, or else, it is missing something here.. I don't know what.
OK, to make SURE this was working, I added the following claim rule:
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "Admin");
Yep, added it right to the Active Directory Provider trust, so it would Always add the 'Admin' role. Nada.
I added it directly to the 'Web Application' / Issuance Transformation Rules, so there is no chance that it wouldn't be added.... Nope, nothing.
I also verified that the 'role' was in the claim description, and checked to publish as both accepted and sent...
Still getting the same old 10 items in the JTW that I always got..
Oh, and I tried restarting the 'Active Directory Federation Services' service...
And marked 'clear browser cache' when the debugger is up on the web page.
Sounds like ADFS just doesn't actually work, or none of the claims rules run. Is there a global setting somewhere that says 'enable custom rules' that needs to be turned on?
This is a better article since it doesn't reference SharePoint.
Also the rules should be "issue" rather than "add".
On the RP side, add the claims rules.
You need a RP trust because this is the application that is going to get the claims rules.
To add a RP trust manually, refer this.
Also, you mention JWT? What protocol are you using? SAML? OpenID Connect?
Turns out that you can add the rules to the 'Application Group' / "Web Application", and select the "Issuance Transform Rules" and add your SQL Claim rule there:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "SQL", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT role from dbo.ADFS_attributes where logon={0}", param = c.Value);
This allows you to add multiple roles if you have multiple roles.
The primary reason I wasn't seeing this was that the UI that was put on this was (somehow) posting a different token (without my roles) back to the API Server. I'm looking into where it got that token, why the token wasn't validated, (didn't come from the server, or it would have had my roles added)... Very strange,
Solved the issue by using PostMan to post to the server and then looked at the returned JWT that was good...
It seems that all JWT signing verification wasn't done by the last person...
Related
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
Please read this carefully, as I'm pretty sure people will answer a different question to the one I'm asking.
I have an IdentityServer4 server, that allows users three methods of authentication (we have multiple sources of truth at the moment): custom (userid/pwd in SQL), ldap (user/pwd in AD) & integrated windows (no password required). These work lovely, and when I'm in my client MVC application I can get at the identity and claims, regardless of which method I used to authenticate.
The question I have is how do I understand which user has logged on to the SERVER (not the client MVC!). I can see the server is maintaining cookies, which must hold this info. Bear in mind that User.Identity.Name will return the Windows Authentication information before they have 'logged in' to my software. i.e. User.Identity.IsAuthenticated always returns true. They may well go on to choose the SQL authentication method.
I'm guessing that is has something to do with HttpContext.Authentication.GetAuthenticationInfoAsync but I'm not clear on what authenticationScheme to pass in, as the last call to SignInAsync called an overload that didn't specify that.
Ok, I understand what is going on here now. The way I check to see if the user is authenticated on the server is to check for the sub claim. That will only be present if they've been through the authentication process.
var sub = User.FindFirst(JwtClaimType.Subject)?.value;
If that's null then I know they're not authenticated. If it's not null then I know I can read the JtwClaimType.Name and it NOT be their Windows Authenticated account name.
I have identity server 4 setup and my asp net core app working with it. If you hit a secure endpoint it redirects to Identity Server and you can login. Once you login it then redirects back to the url you were originally trying to access. What I would like to do is check that you have registered in my database before you get redirected. I thought that I could change 'RedirectUris' to a url of my choice but when I do that it has no effect. A breakpoint on that end point is never hit. What do I need to do in order to setup a post identity server login registration screen?
Is this the right way of doing it?
Thanks
Michael
If I understand your problem correctly, you want to get the user details in your application.
IdentityToken contains user name if you include Name scope.
If it is a web application then you may find the name on ((System.Security.Claims.ClaimsIdentity)User.Identity)
You can also add claims as you need, like userid, role etc
Comment
should each client have to 'register' a user with my api specifically?
What's the norm?
Depends on your requirements and what you are requesting for. On my case user must have allowed scope to access the api
I am checking SonarQube 5.4 and the latest LDAP plugin 1.5.1. There are however a couple of issues.
First. My AD account is majcicam. If I log in with it, it is correctly shown in the users list. However if I login with MajcicaM (note capital letters) another additional user is added to the list:
As you can see from the attached image. For every login that I do make, seems it is treated as case sensitive and thinks of it as a different user.
Second thing. Once I assign a group to my user, on the next login those settings are gone. Seems that they are not persisted.
Am I doing something wrong? Is this a bug? Are my settings messed up?
Thanks
Mario
No bugs here, just some subtleties about LDAP Plugin configuration and behaviour. :)
Case-insensitive login
Set sonar.authenticator.downcase to true when delegating authentication to an LDAP/AD server which is case-insensitive.
Group mapping behaviour
When group mapping is configured (i.e. you manually configured ldap.group.* or you use the windows authentication mode with lightweight AD config), membership in LDAP/AD will override any membership locally configured in SonarQube. LDAP/AD becomes the one and only place to manage group membership (and the info is fetched each time the user logs in).
I've been working with the Azure B2C for a couple of days now and have a few issues and questions:
Url that it creates to redirect for login is formed incorrectly. It contains a question mark twice - after the url, and again after the profile name. This causes a 404 not found error every time you login, log out, etc. For example, the URL it tries to redirect to for login looks like this: https://login.microsoftonline.com/samlmanbc.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_firstdemoprofile?client_id=08fcblahblah. You'll notice a second question mark after the profile name, and that's what breaks it.
If I fix that and try and log in, it doesn't recognize the username / password of my account that's a global admin. It DOES recognize the username / password of a new user I created locally in the directory.
In the OnRedirectToIdentityProvider method, when the request type is authentication, the AuthenticationResponseChallenge is null, which makes this call fail:
OpenIdConnectConfiguration config = await mgr.GetConfigurationByPolicyAsync(CancellationToken.None, notification.OwinContext.Authentication.AuthenticationResponseChallenge.Properties.Dictionary[Startup.PolicyKey]);
I worked around this by using the static string SignInPolicyId for the second parameter. That works fine when an account already exists, but if it doesn't then Azure fails at login and says an account doesn't exist for the user. So what is the right value to use there, and/or how does one initialize it so it isn't null?
The type of a claim that was added to a profile is preceded with "extension_"; is that always going to be true or just for now? For example, I added a property called "favoriteTeam", but the claim type for it is "extension_favoriteTeam".
When you use FaceBook as an identity provider, is there any way to pass along the Facebook access token claim (http://www.facebook.com/claims/AccessToken)? This was useful when using ACS with Facebook because your app can then use that token to make additional calls to Facebook to get data from it.
In relation to issue 1 - I updated my reference Microsoft.IdentityModel.Protocol.Extensions to v1.0.2.206221351 and it started working. I made some updates to other references before this, so if the first one doesn't work, try updating more assemblies from nuget.
This is as expected. A page that signs in "local account" users will not sign in your work or school account (in this case, the global admin user).
Always going to be true. We will be cleaning up the Admin UX to make this more clear.
This is on our roadmap. No ETA as yet.