I'm attempting to create a custom AD FS 2.0 Sign In Page that will allow me to authenticate a user with an RSA SecurID token. I have read through the AD FS 2.0 Step-by-Step Guide: Integration with RSA SecurID in the Extranet, but that doesn't really solve the same problem. It details a scenario that secures the adfs/ls virtual directory with RSA, but once the user provides a valid username and passcode they are simply directed to the AD FS sign in page where they would need to enter their AD credentials to be authenticated.
I also looked at the RSA SecurID Web SDK, but it seems to primarily deal with provisioning and retrieval of tokencodes.
Finally, I've look at the RSA Authentication Agent for Web for IIS but it appears to only provide mechanisms to add, modify, or delete data within the authentication browser cookie.
Given the existing AD FS extensibility points, I believe I need to create a custom Forms Sign In Page. Instead of using the existing username/password authentication against active directory, I want to prompt for username and passcode and validate again the RSA Authentication Server. Once validated I then need to have AD FS accept those credentials as a valid active directory user, generate the appropriate SAML ticket and redirect back to the application provider federation service to continue the federated authentication flow.
That's where I'm stuck. I can't seem to find any mechanism to validate an RSA Tokencode in code (C#). If I could do that, I believe my next step would be to implement a custom ASP.Net Forms Authentication module, but I'm not entirely sure that's the right way to go.
Mike
Seems nobody has an answer for this yet. I have the same issue and at this point it looks like it will be custom .net development using the SDK
http://www.emc.com/security/rsa-securid/rsa-securid-software-authenticators/web-sdk.htm
Have found nothing from Microsoft in sample code or the like. RSA just tell you to go and do custom development yourself.
There is apparently also a RSA Java SDK (authapi.jar) although this is not available on any of the public sites. I will be contacting RSA support to see if I can obtain the Java SDK.
Related
I need to provide an SSO between two independent applications via the Azure AD SSO.
My app (A) use Firebase as the backend and currently isn't registered in Azure AD.
The second App (B) is registered in Azure AD via App Registration and I think has password-based login now (but it doesn't really matter). Can't say what technology it uses for the backend.
I've read a lot of Azure documentation but can't understand how exactly should I connect them with SSO.
I see that I can connect applications from the Enterprise Applications list. Is this the only way to do it? In this case, I need to publish my app to the Enterprise Applications gallery but it feels like an overcomplicated solution.
SSO feature and experience depends on the type of auth-protocol being used. It also varies based on that. Lets say, your app uses OpenIDConnect then the SSO experience would be something like what mentioned here: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-oidc-single-sign-on
If it uses SAML as the auth-protocol it looks something similar to: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-saml-single-sign-on
and if its using Password-based SSO then: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications
Specifically for Password-Based SSO, it provides SSO by storing the credentials in the browser extension. With password-based sign-on, users sign on to the application with a username and password the first time they access it. After the first sign-on, Azure AD supplies the username and password to the application.
Password-based single sign-on uses the existing authentication process provided by the application. When you enable password single sign-on for an application, Azure AD collects and securely stores user names and passwords for the application.
Choose password-based single sign-on when:
An application doesn't support SAML single sign-on protocol.
An application authenticates with a username and password instead of access tokens and headers.
In your case, both you apps (MyApp-A and MyApp-B) needs to be registered in AAD and they should support neither SAML or OIDC.
How can I validate a username/password against Azure AD without showing a UI? I have an autonomous processes running (think Windows Service or scheduled task) where the username and password are stored in a configuration table.
Since there is no "user at the wheel" so to speak, we can't use the normal method that shows the Azure login page (https://login.microsoftonline.com/{tenantId}).
1. Just make it work, no changes approach (Not Recommended)
You can try to get a token using Resource Owner Password Credentials Grant. (ROPC might be the least secure among all the different grants supported and brings potential attack risks. Also note that ROPC doesn't work with MFA and has issues with federated authentication users or may not work in those cases at all)
I don't think there is any method/endpoint available to specifically validate the username/password, but the workaround is if either username or password is incorrect, you will get an exception from the token endpoint when using ROPC, otherwise you get back a valid token which means credentials are good.
You can read about how to get a token using ROPC here:
Resource Owner Password Credentials Grant in Azure AD OAuth
2. Suggested Approach, some changes required (Recommended)
This might feel a little inconvenient at beginning, but it will be well worth the effort from a security standpoint. Note that this approach as well as the first one will meet your requirement of not going through normal login page as well.
Since there is no "user at the wheel" so to speak, we can't use the
normal method that shows the Azure login page
(https://login.microsoftonline.com/{tenantId}).
As you mention that the autonomous process is like a Windows Service or Scheduled task, from Azure AD and OAuth 2.0 perspective your process looks like a Daemon service. So instead of using a username/password credentials directly from configuration, which violates security best practices, you should be looking at using Client Credentials Grant. It's strongly advised NOT to collect/manage/store end user credentials (or create old world Service Accounts) directly in your applications.
You can read about it in detail here: OAuth 2.0 Client Credentials Grant with Azure AD.
Also visit this documentation for all Azure AD app types and scenarios, specifically those listed for Daemon apps. Link
To put it very briefly, your process gets represented by a registered application in Azure AD and for credentials part you can use:
a. Client ID + Client Secret Key (provided by Azure AD specifically for your application. you can generate more than one secret keys for different purposes with different expiration etc.). Sample C# code with Client Secret
b. Client ID + Certificate (pass a JWT that you need to create and sign with the certificate you registered as credentials for your application). Sample C# code with Certificate
I am working on a Intranet application where i am calling a SAP service from a ASP.NET WEB API, Currently it is working fine with a HttpBasicAuthentication with a predefined user name and password. But now the requirement is to get the logged in windows user's user name and password through ASP.NET WEB API and pass it to the SAP service for authentication? Can anyone help me on this?
1) HttpBasicAuthentication won't apply in this case.
2) Use identity impersonate via the web.config tag (ref Identity Impersonate) to have the current user's identity taken up in api. However this will only work for Intranet based applications and not over internet. For Internet based, you will need to have Kerberos bridge (somewhat complicated) concept implemented.
3) In you app.start method, you need to set the current principal to windows principal.
Then you can have the user detail available..
Please note that you will not have the user's password available as OS protects that very very securely. You can get the user's Kerberos token though which your target system can auth against the AD being used.
What is the best method of securing a REST Web API with the following requirements. The system has an Angular JS frontend with the REST APIs implemented in ASP.net.
There are two "roles" in the system, users will have one of the
roles. One role should allows access to some APIs (call it "VIEW"),
the other role allows access to other APIs
All users are in Active Directory, so if I have a username, I can check what role they are in- Some clients are on Windows boxes, the others are on Linux
I would like to persist the session so I don't have to look up AD for every API call
I would like single sign on. On the Windows machines, I don't require them to enter user and pass as I already can retrieve their username using Windows Authentication.
I believe that Oauth would be my best option.
There are two "roles" in the system, users will have one of the roles.
One role should allows access to some APIs (call it "VIEW"), the other
role allows access to other APIs
For role based authentication, you can use [Authorize("Role" = "Manager")]. The token will be provided by the identity server and will contain the claim as Role.
All users are in Active Directory, so if I have a username, I can
check what role they are in- Some clients are on Windows boxes, the
others are on Linux
If you have ADFS then you can have an Identity server that trusts the ADFS. The ADFS will provide a token which will have the claim for role and your Identity Server will do the claims transformation and will return the same Role claim back to angular app.
I would like to persist the session so I don't have to look up AD for
every API call
For this while requesting the token, you can ask for offline scope so the Identity server will provide the Refresh Token with Access Token so you don't need to ask for AD again and again.
I would like single sign on. On the Windows machines, I don't require
them to enter user and pass as I already can retrieve their username
using Windows Authentication.
For this one, you can have your Identity sever trust the WSFederation for windows Authentication.
So basically you need to setup Identity server that will provide you with the token and the REST API will use that token to verify claims to return the correct information back to the user.
I am not sure what you expect exactly. Anyway, first I'm gonna reformulate your question with requirements:
you accounts and role are in active directory
you want to manage roles based on an active directory group
you want anybody whatever the system (windows, linux, mac, mobile...) to connect on your application using the same authentication
you want to avoid your AD to be hit constantly (not at any call for example)
if the user is connected on an application that uses the authentication system, he doesn't have to do it so again on another application that uses the same authentication system
If these requirements are yours. I believe the only standard (and clean) solution is to use OAuth. I'm not gonna go in detailed description of OAuth, but this authentication protocol is the most standard one on the net (facebook, google, twitter...). Of course as you don't want to use facebook, google or twitter accounts in your business applications but your active directory accounts you'll have to install/setup/develop your OAuth identity provider using accounts of your active active directory server. Your choice will depend on how well you know ADFS protocol and its different flows (code, implicit, assersion) You have two solutions for it:
Use ADFS: install ADFS; it provides a OAuth portal that will work out of the box with asp.net mvc. This uses the code flow of OAuth that is the only OAuth flow supported by ADFS. For roles and its related AD groups, you'll have to map role claims with AD groups. (it's in the setup of adfs, you'll find many tutos on the net). You'll find lot of tutos as well about how to use ADFS with asp.net mvc/asp.net webapi. I mention .net here, but every technology has an implementation for OAuth authentication (nodeJs/express, php, java...).
Use thinktecture identity server (.net technology). This will provide all the foundation to implement a custom identity server with the least effort: http://www.thinktecture.com/identityserver / https://github.com/IdentityServer/IdentityServer3. It contains an addin to plug its accounts to active directory. With this, you can use implicit and assertion flows.
Use oauth2orize (for nodeJs): https://www.npmjs.com/package/oauth2orize. This will permit you to make the same than thinktecture identity server but in nodeJs. Apparently you'll have to make all the wirering with ad manually. With this, you can use implicit flows (not sure about assertion flows).
At application side, most of frameworks can authenticate easily using OAuth with a lot of existing frameworks. For example, even if you make a single page application, you can use adal.js or oidc.js for angular if you use angular. As I mentioned above, all this is taken in charge by asp.net mvc/webapi out of the box but I know it's the case for other server technologies. If you have more questions, don't hesitate as I'm not sure of what you expect exactly.
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.