Announcements

SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.
GhiathEzzeddin
Beginner
Beginner

Can I use RSA SecurID on Personal email

Jump to solution
0 Likes
1 Solution

Accepted Solutions
BrianTwomey
Employee
Employee

Hi Ghiath, unfortunately not. In order for us to protect OWA for example we need to load the IIS Web Agent onto the Exchange server. We don't protect Outlook itself but rather the URL that you use to access OWA. To protect Gmail or Hotmail they would need to be using either IIS or Apache and would themselves need to install the RSA agent. It's not something an end-user would be able to perform.

View solution in original post

4 Replies
BrianTwomey
Employee
Employee

Hi Ghiath, unfortunately not. In order for us to protect OWA for example we need to load the IIS Web Agent onto the Exchange server. We don't protect Outlook itself but rather the URL that you use to access OWA. To protect Gmail or Hotmail they would need to be using either IIS or Apache and would themselves need to install the RSA agent. It's not something an end-user would be able to perform.

EdwardDavis
Employee
Employee

Maybe. Google and other companies have 2-factor of their own. At an enterprise level, you maybe could use RSA VIA Access and integrate your existing Securid enterprise and tokens authentication with [whichever cloud provider like Google] but this is corporate level stuff. So, you want to ask RSA Sales if VIA will allow you to integrate with [whatever you want to use your tokens with]. And you probably need some type of agreement or contract with [that cloud provider].

 

 

To add to what Brian posted, you could configure your own exchange server to pop mail off gmail or hotmail, and use RSA Securid web agent for OWA.

That would force a token to get mail from gmail or hotmail, but it would not force tokens to be used if you accessed gmail or hotmail from outside the exhange server.

GhiathEzzeddin
Beginner
Beginner

Dear all,

Appreciated your helpful answers.

 

Best regards

Ghiath

0 Likes
JayGuillette
Apprised Contributor Apprised Contributor
Apprised Contributor

To kind of add to what Brian and Ed already explained, SecurID Authentication Manager, AM, protects resources such as servers, VPNs and Web Sites by requiring challenged users to authenticate by entering a Token PassCode instead or (or in addition to) a Password.  So from an Authentication Manager, AM Point of view (Brian's answes), you cannot protect your Gmail account with AM because Gmail is not your resource, it belongs to Google and they grant you access to it.  However as Ed pointed out they (Google) might be able to, or would have to grant you the option to authenticate with something other than a Password, e.g. a SecurID Passcode from a SecurID Token.

 

Ed also suggested another RSA product, Via Access, which is used to protect cloud based applications.  A common application is SaleForce, which is cloud based but authentication can be controlled locally by a SaleForce Customer, so that UserIDs are not re-created by Sales Force in the cloud, they are accessed locally on the customer site in the customers LDAP directory source such as Active Directory (this is known as the Hyrid cloud approach).  Via Access lets you control Users, Passwords and authentication locally, so that local Active Directory UserIDs and Passwords allow access to the cloud based Web App such as Sales Force. The list of cloud based applications can get long and fuzzy, but the short answer is any Application that supports SAML can be protected with Via Access.

Via Access also lets you put a SecurID Passcode authentication requirement (or bio-metric requirement, or Smart phone acknowledgement requirement, or some sliding scale option between Password on the low risk end up to Passcode on the high risk-end Risk-Based Authentication, RBA requirement.  I do not know if this is possible with Gmail, it would depend if Google allows for that.  You may want to contact RSA Sales if you are interested is some type of deployment of a strong Authentication, Access Control or Compliance, or Analytics system.

 

When considering the Big picture it is important to keep the concept or task of Authentication separate from the concept or task of access control or authorization (think permissions or ACLs or rights which can be organized by groups or roles).  Access control or Authorization is the focus of much of Security, but Access Control or Authorization is only as good as your Authentication.  If you cannot be sure that SuperAdmin or root UserId GEzzeddin.admin is really GEzzeddin.admin because someone could have hacked or stolen GEzzeddin.admin's password, then you cannot be sure about your entire Access Control Security.

 

Strong Authentication is the real medicine for breach uncertainty based insomnia

0 Likes