We are having a hosted web application and it uses forms authentication.
This webapplication is accessed by users belong to different partner organizations.
Currently users belong to the partner organizations are accessing the application using the credentials that we give it to them.
Now, some partner organizations wants their users to access the application using their active directory credentials.
We are planning to use ADFS for these partner organizations, so the users will be authenticated using Active Directory within their network and claims will be sent to the webapp via the Authentication token cookie set by the ADFS. From the claims, we map the users to the internal userIds of the web application.
My questions are , if we make the web application ADFS enabled,
1)Is it possible to still allow the other partner organization users(who don't want to use ADFS) to login to the web application using the existing login page(forms authentication)?
2) Should every page in the ADFS enabled webapp be accessed through https?
Any solutions or pointers would be much appreciated.
Thanks
-arul
Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.
Related
I'm working on a web application that uses OpenId authentication. Let's assume that the application essentially serves to store metadata and its associated files (docx, pdf). The Web Application is for internal use and is not exposed to public network, only users of the organization have access.
Recently, a requirement has arisen to be able to share files with users external to the organization. External users will use a PORTAL (third-party application) which, through a URL generated by the Web Application that points to the PORTAL, will have access to the file. This PORTAL uses OpenId authentication and invokes a Web Application API to retrieve the file.
Initially, the proposed solution was:
Web Application - Send EMAIL to the external user and create a user in Keycloak with Email to authenticate later on the PORTAL (Is this really necessary?! Biggest doubt).
The external user accesses the PORTAL with the URL received and authenticates with the user created by the Web Application on Keycloak.
Once authenticated on PORTAL, a WebApplication API is invoked to obtain the file.
The main question is whether the Web Application should manage the creation/editing/deleting of external users on Keycloak. Does the Web Application need to create users in Keycloak? Is there another way to accomplish this without compromising security?
Thanks in advance.
To share a file with restricted access, there are two approaches:
Open access with signed links: Create a signed URL using a web API and share it with external users. The link can be a static URL with an encrypted key, or a JWT signed token in base64 form generated by the web API. When the portal receives a request, it checks the validity of the token, retrieves the file location from the token, and allows access.
Email-restricted access: If you want to guarantee access only to the person with email xxx#abc.com, you'll need to use a challenge, which is typically a login. You can either create users on the fly after login (if the external users come from a partner with OIDC capability), or pre-create the users if this is not the case.
Note: You cannot rely solely on a URL with an email claim as proof of access, as the link may have been forwarded to someone else.
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.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I have developed a web application (spring mvc, spring security) which has a its own login.
Now I want to change the application to login with an another web site's (2nd web) credentials and also need to get some user details from 2nd website.eg: username, user role list for create authentication object.
Please help me to choose best way to do this.
Is openID or oauth2 better for my client application?
OpenID and oAuth are 2 different things.
Lately, Google announced it stops supporting OpenID, so maybe oAuth2.0 is a better option for you.
Note that if you choose oAuth of 3rd-party, you force your users to have account there. for example, if your application (the resource server) uses Facebook for authentication/authorization, your users will HAVE TO have account on Facebook (you want that?!).
If you work with OpenID, your users have several options of where to hold their account...
If you have another 3rd party (or in-house, it does not really matter) authentication server and you want to authenticate your users with it - you have to know what specifications it supports. For example, if it supports oAuth2.0, you can pretty easily configure your app to work with it.
Hope that helps...
If I understand you correctly, you are talking about using Social Networks like Google+, Facebook, to be able to login to your application (This is identity services, where you don't have actual password, but rather access token with limited scope).
For that there is a Spring Social, project, that provides set of abstractions, for such kind of integration, including additional Spring MVC Controllers, needed for proper authentication in this Social Networks.
We are building an ASP.NET MCV 3 application from scratch running on Windows Azure. About Authentication and Authorization layer we are thinking to use the Access Control Service. I went through some articles about ACS where I got the basic idea but I still have some doubts on it.
My understanding is that using the ACS we outsource the Authentication process to one or more Identity Providers (IP), basically we trust another system (i.e. Microsoft Live ID) to authenticate our users.
The basic process is very straightforward: at authentication stage we redirect (ACS does it) the user to one of our “trusted” IPs, that will redirect the user (with a valid token) to the ACS and eventually to our application.
Here comes a number of questions:
Since we don’t want that all the users with a Live ID account can access to our application, I presume there should be another process to validate that user and checking if he is registered in our application. The question is where? In the ACS or in our application?
I have an idea about this but I don’t know if it’s the right way to do it:
At registration stage, the system (our web app.) asks the user which IP (i.e. Live ID, Google, Facebook, and our app.) he wants to use to authenticate himself in the application. Then the user goes through the authentication process on the IP system and when he comes back, we store his username (IP username) in our DB.
So, next time, at authentication stage we can check if that user is registered in our system.
If the above theory is correct, that means in our app. we need to build our membership provider to store usernames coming from IPs and users that chose our app. as IP.
Am I correct? What is the best practice to design the above process?
Now let’s talk about Authorization and “Roles”. How does it work with ACS? Does ACS manage multiple roles per user?
Again my understanding is that with ACS you can create a number of “Rule groups” related to the IP and not to a single user. If this is correct, how do we manage users in role in our application? Let’s say, for example, that we have multiple roles and our users can be associated to those roles, can we use ASC to manage it?
So the final questions are: Does ACS itself cover the whole Authentication and Authorization process? Do we still need to use the .net Membership Provider? What's the best practice in order to cover our requirements?
For the part of the question about the registration stage, the best thing to use to identify users is the NameIdentifier claim type
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.
This should be unique for each identity provider and also fixed. If you use the email address claim, it could change for the same user. Technically it could be possible for two identity providers to use the same NameIdentifier (none of the out-of-the-box ones with ACS do) so you could combine the NameIdentifier claim with the IdentityProvider claim type
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
to guarantee uniqueness.
For the part about role, I would say using ACS to issue role claims from generic identity like Google would be quite hard to manage using the claim transformation rules in ACS on per user basis. You would have to add a rule for each registered user - probably not feasible. I think the ACS rule groups are more suited to transformation of role claims (e.g. issued by a federated ADFS). Your idea to do it in your application is a better one IMHO. In code, the place to do this using WIF is in a custom ClaimsAuthenticationManager. You override its Authenticate method and based on the NameIdentifier claim from the incoming principle, you look up in your membership datastore and create a new IClaimsPrinciple based on the roles that are in your membership DB (i.e. you add a role claim for each role the user is in).
You then make your authorization decision in a custom ClaimsAuthorizationManager. There are some good samples and info on this around on the web. You can start at
http://msdn.microsoft.com/en-us/library/ee748497.aspx
The user validation process is done with claims.
After you set up an IP with ACS, when users authenticate, ACS will get claims about the authenticated user from the IP. You need to configure rules in ACS to say which claims you want forwarded on to your application. You can also tranlate claims into different types, to normalize the incoming claim set to what your application expects
If you want to implement your role based access with ACS, you can. In this case a role just another claim ACS will issue, and you'll implement your application to give user privileges based on the role claim it receives from ACS.
You can configure ACS rules that map certain IP input claims to role output claims. ACS also has a management service that can change these rules so you can implement a user registration process.
Individual claim rules in ACS relate to identity providers that issue the claim, but rule groups don't. Rule groups associate to RPs (your applications). A rule group is simply a group of claims transformation rules that tell ACS: "for this application, apply this rule group policy when you issue the token".
The ACS docs have lots to say about ACS claim rules configuration, both through the web portal and through the management service::
https://msdn.microsoft.com/library/azure/hh147631.aspx
Expanded response:
Let's say you're using ACS to authenticate to an ASP.NET app that's using WIF. You would configure ACS to issue a Role claim of "Manager" for the google user with email "jdoe#gmail.com".
Now in your ASP.NET app, WIF will see this role claim and it will allow you to control access using either HttpContext.Current.User.IsInRole("Manager"), or the web.config equivalent.
You can manage these ACS rules manually using the web UI, or you can implement a registration process that adds such rules to ACS programatically using the ACS management service. There are some ACS management service samples available at acs.codeplex.com.
Also, the identity developer training kit has some examples on WIF role based access:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347