ADFS 2016 supports a new claim type "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup" which contains the Windows devices group SIDs. How may I cast the claims on a simple claims aware ASP.Net Application ? I am on VS 2015, .Net 4.6. What are the minimum requirements to grab this claim type and its value from ADFS so I may use it. Any code snippet would be highly appreciated.
I need help in getting the code that can do something like this but for a Windows Device -
ClaimType - http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup , ClaimValue - S-1-21-5-xxxx-xyyyy-zzzzzz.
Where S-1-21-5-xxxx-xyyyy-zzzzzz is the SID of a Group the computer is member of.
Also, Any chance that this claim type may be used with ADFS 2012R2 ?
This uses the compound authentication pattern that was released as part of WS2012 Active Directory. See https://www.microsoft.com/en-us/download/confirmation.aspx?id=36830 for details on it. Look for the compound authentication section. Then you need to pass the necessary claims by modifying the ADFS's claims provider trust for "Active Directory". Now you have those claims that can be consumed by a downstream application.
Note that this works through Kerberos. So, only if the client is inside the corporate network with line of sight to the a correctly enabled domain controller, will this use case light up.
Thanks
//Sam (#MrADFS)
Related
I've been developing an application that uses SSPI for Client / Server authentication. Everything works fine, but still one question remains.
The first argument of SspiPromptForCredentials is the target name... But what is it really used for?
I can literally put anything as a target name, my code will work. I don't even see it written anywhere (in the GUI).
Is it related to the authentication method? I use Negotiate.
Thanks for your help :)
I think it might be related to how the credentials are saved in the credential manager.
The only SspiPromptForCredentials example I can find on MSDN just uses a simple useless string ("Target").
For CredUIConfirmCredentials MSDN says:
Pointer to a null-terminated string that contains the name of the target for the credentials, typically a domain or server application name.
This must be the same value passed as pszTargetName to CredUIPromptForCredentials or CredUICmdLinePromptForCredentials
CredUICmdLinePromptForCredentials has a similar parameter and for this MSDN says:
A pointer to a null-terminated string that contains the name of the target for the credentials, typically a server name.
The pszTargetName parameter is used to identify the target information and is used to store and retrieve the credential.
...
Credentials are stored in the credential manager based on target name. Each target name is stored as generally as possible without colliding with credentials already stored in the credential manager. An important effect of storing credentials by target name is that a particular user can have only one credential per target stored in the credential manager.
These other CredUI functions are perhaps lower-level but I think the parameter usage is the same.
MSDN says this about Negotiate:
To allow Negotiate to select the Kerberos security provider, the client application must provide a service principal name (SPN), a user principal name (UPN), or a NetBIOS account name as the target name. Otherwise, Negotiate always selects the NTLM security provider.
The answer is a little more benign than you might think. SSPI supports arbitrary credential types, so the API needs to provide a way to prompt for credentials that a particular SSP understands without having to expose a 3rd party API. You can't launch a UI from within the SSP itself because it runs in LSA, so there's an implicit contract between the app builder and the SSP builder that if you need special credentials you're going to have to call SspiPromptForCredentials.
In some cases it's possible that SSP you're trying to use might require knowledge of the target to form the shape of the marshaled credential. Often times it doesn't.
Negotiate just happens to not require that information because the credentials you enter are not dependent on the target.
I have an MVC application (.Net Framework 4.5) which is been there for the last three years and using Forms Authentication mechanism. This application provides different accounts like Personal, freebie, Enterprise etc. For an enterprise account, we are handling everything in the same application. I.e. Suppose an enterprise called “xyz” created an enterprise account with the application, then we are providing a custom URL like “https://application/xyz/login” and from the URL we are identifying that enterprise. I don’t know the exact reason why they implemented like this as I have seen applications that are having enterprise accounts are created as subdomains (e.g. https://xyz.okta.com). Now the client asked to integrate Okta into this application.
So I looked into Okta and found SAML is the right way to do and ends up in KentorIT Authservices. Initially, I was able to integrate this with a sample MVC application and the authentication part was working fine. With some basic idea about SSO, I have started integrating kentor authsevices into my application. The challenges I found in this implementation are:
1) For Enterprise accounts, Okta configuration settings are different for each enterprise and with my current application implementation, it is not possible to set it in from the web.config. So I have tried to set it from code and I was able to integrate those settings by replacing Configuration.Options.FromConfiguration;. I’m planning to store all configuration related things(Single sign-on URL, Audience URI,Identity Provider Issuer" etc.) in the database so that I can get the information whenever I wanted and I’m assuming that “Identity Provider Issuer Id is unique for each Okta account. In an IdP initiated flow, when the user tries to access the application it will redirect to AuthServices\Acs action method and from that, I’m trying to read the configuration settings. From the request is there any way I can identify from which Okta account call came(like Identity Provider Issuer)? Currently, I set the "Identity Provider Issuer" value (and I think which should be unique for okta account) to the Default RelayState field under General SAML settings tab and I was able to retrieve it from AuthServices\Acs action methods. Does it seem to be a good idea? Please advice.
2) The Enterprise accounts are limited based on the number of licenses (say 50). Suppose if the Enterprise Okta admin intentionally added 55 users all those users can successfully authenticate the application based on the default settings. Is there any way I can handle this scenario. Do I need to keep a record of the list of users that came under a particular enterprise account?
3) From the documents I understand that Kentor authentication service is only for authentication and authorization part has to be done from the application itself. The current application implementation consists of a custom authorization attribute which checks for user permissions that are stored in the database. That should be there as it is and we have to do the authorization based on database permissions. Right?
Expecting your valuable suggestions and please correct me if I'm wrong. Thanks in advance.
Don't use the RelayState for sensitive data unless you cryptographically sign it. It is not protected by any signature when using the POST binding, so the user may manipulate it. To get the issuing idp, check the issuer field of any claim generated by AuthServices instead.
Yes.
Yes, that's the whole idea with Kentor.AuthServies: To plug SAML2 authentication into the security model of .NET to allow you to use any current/traditional Authorization setup.
I hope I am not being to dense but I don't know how to use phpoidc. I have downloaded phpoidc from https://bitbucket.org/PEOFIAMP/phpoidc. I have followed the instructions in the INSTALL file. Now that it it supposedly installed, how do I use it? There does not seem to be any documentation on this.
I just want to set up simple user authentication on my site. I am running CodeIgniter 3.0 rc. I primarily want to allow login with google accounts.
Are you talking about the OP side or RP side?
OP side should be quite self-explanatory as it is a stand alone thing.
RP side needs integration to your application.
The phpRp is just a sample implementation that uses these libraries.
What it does is to create an OpenID Connect request and process the call back to see validate the response. Then, typically, an application needs to associate the iss and sub in the ID Token to a local account: you need a mapping table for it. Once you are done with that, create a session and off you go.
I am using Windows authentication on a website but want to have levels of access. Currently, I am using the [Authorize(Users = "userA")] syntax.
However, with upwards of twenty Windows accounts accessing a site, I don't want to have to hard-code in twenty users with each Authorize statement. What's more, some of the users need to have different access than others. I thought of having a list of users that a CustomAuthorizationAttribute iterates through to see if the desired user is among them.
Basically, I'm trying to get roles without using Forms authentication.
What is the most effective, most simple way of doing this?
Your answer lies within the ActiveDirectory domain. Since you are using MVC 3 you should have access to the following namespace "Directory Services Account Management":
http://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.aspx
You can see this article for describing the whole process underneath, it provides sample code for you to use immediately out of the box:
http://msdn.microsoft.com/en-us/magazine/cc135979.aspx
Forwarning:
You will also have to establish an LDAP connection string. LDAP is a protocol used for retrieving that information from the secured windows database.
http://technet.microsoft.com/en-us/library/aa996205(v=exchg.65).aspx
To see the code being used in action:
http://www.willasrari.com/blog/query-active-directory-users-using-c/000133.aspx
I've done something similar to this in a .NET 3.5 environment using IIS 7.
One of the best articles I've ever read about Role-based Authorization is:
Role-Based Authorization With Forms Authentication (Part 2) By Darren Neimke and Scott Mitchell. They wrote it for ASP.NET 2.0, and no concept has been changed in version 4.0 (and 4.5 as far as I know).
To become a master in this field, read this MSDN and all of it chapters:
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
I have an ASP.NET MVC 3 web site that uses Windows Authentication running under IIS7.5. This web site also checks manually for groups in AD using the GetRolesForUser method of a custom RoleProvider. This isn't anything special, and has been working fine for a few months now.
However, we now have a user that had their Active Directory user name changed. They still have the same actual AD account, but to them their login name is now different.
Unfortunately this has broken the web site for this user. I'm using Elmah to log errors, and I have noticed that REMOTE_USER is using the old account name, and LOGON_USER is using the new account name. It looks like the username parameter of the GetRolesForUser method is getting the old account name - so I assume it is using REMOTE_USER.
Should I be targeting the web server or the web site for a fix? I've read that LOGON_USER and REMOTE_USER are only different if there is an authentication filter installed. I'm not aware of anything like this on the web server (although I'm not sure exactly where to look), but does MVC3 add this somehow?
Typical, after I posted, my Google-Fu kicked in.
Seems like this is a known issue (by design) with the local sid cache:
http://support.microsoft.com/kb/946358
Resolution is to follow the registry change in article (and undo it again?), or reboot the web server. I have read that a IISRESET might fix this too.