I have installed shibboleth 3.0.2 version. I am hosting a single page application, which needs to be protected through ADFS login. There are two ADFS for different set of users.
I have few queries as how to achieve this.
How can i configure two IDPs in shibboleth2.xml file. element is allowed only once. I have provided two tags with different metadata file but when I click the link
https://devserver.testhost.com/Shibboleth.sso/DiscoFeed, it shows me two "entityID" elements with same IDP provided in .
How does system work with two IDPs. What should be the process to identify when to call which IDP.
Like with single IDP, I can do something like below in my Apache configuration. Whenever the context path is hit, apache will redirect the call to shibboleth, and shibboleth to IDP.
<Location /my-first>
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
But I am bit confused, as when there are more than one IDP, how to decide which one gets called.
Can you help me with the above queries.
Thanks
You need to run the Shibboleth Embedded Discovery Service (EDS)[1] in conjunction with your Service Provider installation, so that when a user requests a protected resource, i.e. /secure, they are kicked over to the discovery service which prompts them to select the Identity Provider they would like to authenticate against.
The /Shibboleth.sso/DiscoFeed url is used in configuring the EDS, so that it knows the details of which Identity Providers are configured for the service provider, and what information it should include in the drop-down.
The EDS is little more than some Javascript to parse the JSON and create the appropriate URLs for the users to select with the drop-down, but it's exactly what you are needing here.
[1] https://wiki.shibboleth.net/confluence/display/EDS10/Embedded+Discovery+Service
Related
We have multitenant asp.net MVC web site which supports multiple partners. Currently we are using forms authentication to authenticate users. Now some of the partners have asked for single sign on support with SAML.
I did quick POC to test it against “Thinktecture” identity provider. All I did was to install “Identity and access” extension for VS 2012 and configure the identity provider. I noticed that the extension added configuration settings like URL of the IP and realm in the web.config file. It also added “WSFederationAuthenticationModule” module to handle the authentication. This module was handling all the redirects and the validation of response behind the scene.
In my case since we will have multiple identity providers, depending upon the partner, I will be choosing the Identity provider. The URLs of the different IPs will be stored in the database. I cannot list all the IPs in web.config. Hence I need mechanism in which I can redirect user to appropriate IP URL and once the IP posts back the result, verify the result and retrieve user information through claims. I don’t want to do the XML parsing of the result and validate the response, but just want to call methods in “WSFederationAuthenticationModule” to do the heavy duty work. But I am not sure which methods will be useful for me. Can somebody help me out or list of the sequence of methods I need to execute to achieve this?
Take a look at my simple example
http://www.wiktorzychla.com/2014/11/simplest-saml11-federated-authentication.html
The trick is not to have the WSFam module in the pipleline but rather use its api to trigger redirects and consume responses. If you follow my code, you'll see there are two clauses
// wsfed response or not
if ( !fam.IsSignInResponse(...) )
// redirect to provider
else
// create local config and validate the incoming token
This simple example is perfectly suitable for multitenant scenario, in fact we use ws-fed daily in multitenant environment and most clients are based on this core approach.
Namely, creating the SecurityTokenHandlerConfiguration programatically in the branch that consumes the response gives you total control over how you validate tokens for different tenants.
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
We've got some WCF services we're hosting via IIS. The application in general uses Forms Authentication, and we'd like to continue making that available for web service clients. We just have a <authorization><deny users="?"> in our web.config and some authentication/redirection goodness that gets everything done.
The problem is we'd like for users to be able to access the metadata for the services without authentication. Can they visit /services/v1/ArtifactService.svc?wsdl anonymously and yet still require authentication for /services/v1/ArtifactService.svc/rest/GetArtifacts?studyId=123? If so, I can't figure out the right incantation in the configuration.
The best I can think of is to set an absolute URL in the metadata service behavior, but then I have to doctor the path on install anywhere we deploy. (<serviceMetadata httpGetEnabled="true" httpGetUrl="http://some/absolute/path">).
Any ideas?
I think this is not possible. If you require authorization on the resource by using allow and deny elements you can't specify different authorization level based on url query. You have to control authorization in the service - PrincipalPermission.
I have an (ASP.NET 3.5) intranet application which has been designed to use forms authentication (along with the default aspnet membership system). I also store additional information about users in another table which shares its primary key with the aspnet_users table.
For users who are part of our domain I store their domain account name in the secondary users table, and I want to automatically log in users whose domain account name matches a name stored in the table.
I have read the guides which are available - they're all from two years ago or more and assume that you are able to activate Windows Authentication on a separate login page that allows you to extract the domain account name. From what I can tell, though, this is not possible in IIS7 (the overall authentication method is applied on all pages and cannot be selectively deactivated, and both authentication methods can't be applied on the same page).
Is there a way of getting IIS to pass through the windows domain account name of the requesting user? I don't need proper AD authentication, just the domain name.
Actually, you can do it. Bit late for #dr_draik, but this cropped up in a google result for me so I thought I'd share some knowledge.
If you're in classic mode - Enable both Windows and Forms auth. You'll get a warning about not being able to do both at once, but you can ignore it. Then, you can spelunk around various properties like
Code:
HttpContext.Current.Request.ServerVariables["LOGON_USER"]
and fish the username out of there.
If you're in integrated mode - 4021905 IIS7 Challenge-based and login redirect-based authentication cannot be used simultaneiously leads to IIS 7.0 Two-Level Authentication with Forms Authentication and Windows Authentication which is a module that allows you to selectively change the auth for different pages.
You could always set up 2 separate application in IIS7. One would have Windows Authentication enabled. The other would be the main app with forms authentication. If a user went to the windows authentication app, the page could grab their credentials and pass it to the forms authentication app.
(More for completeness of information really)
I asked a .Net security guy this question at a conference a while back. His response was that it is technically possible, but he'd never seen it done (and to let him know if I did it and it worked!).
He suggested the way it could be done was by making your own ISAPI filter and installing it into IIS. The ISAPI filter would intercept the requests and basically do the job that IIS does when using integrated authentication, but fall back to using forms if this was not present. This involved some complicated challenge/response logic in the filter. This was for IIS6 though, so it might be different in IIS7.
Whilst this might be technically possible, I wouldn't suggest this route as it feels like a bit of a hack, and rolling your own security is never really a good idea (unless you really know what you are doing).
There are plenty articles on mixing the authenticaton by setting config to use the forms with allowing anonymous access to the app. Secondly, a page for integrated auth should be created with IIS settings set to deny anonymous and use Intgrated Authentication. There you would the magic trick by checking the "Logon_User" variable of the requets's ServerVariables collection. And finally for integrated authentication to silently sign in the user it has to have short hosted name. So if your forms authentication piece is exposed to internet via FQDN there should be some kind of redirect to the short host page. I think it is possible to achieve with just one application under IIS with 2 virtual directories.
I found a solution using no special add-ons. It was tricky and involved cobbling together elements from all the pages referenced here.
I posted about it: http://low-bandwidth.blogspot.com.au/2014/11/iis7-mixed-windows-and-forms.html
In essence, forms, windows and anon authentication have to be enabled.
The login screen should be forms based, and contain a button to trigger Windows login, that issues an HTTP 401 response challenge which if successful creates a forms based login ticket.
The issues are rather complex, and the post goes through the principles and the solution in detail.
Unfortunately, what you are trying to do just isn't supported. In order for ASP.NET to know the Windows username, you must use Windows Authentication.
You could set up another site / virtual directory that just forwarded the username information to another page. But what happens when non-Windows authenticated users try to log in?
I've got something you can try - not sure if it will work.
In the past we've used Request.ServerVariables["LOGON_USER"] but obviously for this to return a non-empty value you need to disable Anonymous access.
See this article: http://support.microsoft.com/default.aspx/kb/306359
It suggests keeping Anonymous access on the IIS side, and Forms authentication, but denying the anonymous user as follows:
<authorization>
<deny users = "?" /> <!-- This denies access to the Anonymous user -->
<allow users ="*" /> <!-- This allows access to all users -->
</authorization>
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx