Skip to Content.
Sympa Menu

assurance - RE: [Assurance] RE: Passwords and Office365

Subject: Assurance

List archive

RE: [Assurance] RE: Passwords and Office365


Chronological Thread 
  • From: Brian Arkills <>
  • To: "<>" <>
  • Subject: RE: [Assurance] RE: Passwords and Office365
  • Date: Thu, 7 Mar 2013 07:10:38 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none

The case Etan is describing only happens when the Microsoft account has no password, and is linked (as I mentioned in a recent thread over on Mace-Dir) via an immutable ID so that a federated logon token issued by your on-premise IdP permits authentication to that Microsoft account. I believe this is the SAML ECP profile (but I'm not really a SAML expert, so someone else can correct me).

 

As you've noted, if you choose to deploy Office 365 by creating accounts with passwords, then the only way that would be of relevance to the IAP would be if the passwords were the same as the passwords used with the IdP that wants to issue assurance claims. But I don't think that's the scenario Etan was asking about.

 

From: [mailto:] On Behalf Of Michael R. Gettes
Sent: Wednesday, March 06, 2013 1:29 PM
To: <>
Subject: Re: [Assurance] RE: Passwords and Office365

 

possible example:  if the password used for the purpose you describe is only used by O365 and is different from your institutional SSO password and cannot be used to reset or change a password - then you may have the necessary controls whereby if O365 is compromised, then your accounts aren't compromised… maybe some data is compromised, but the LoA.  At least this is my interpretation and I am sure others will whack me on the head if I got this wrong.

 

/mrg

 

On Mar 6, 2013, at 3:01 PM, Etan Weintraub <>

 wrote:



So, if my understanding is correct, then it is not something that would eliminate the possibility of Silver, but we must implement some type of policy and procedure for if it is compromised at the foreign system. I.e. knowing every account that is on that system, and have a policy that if that system is compromised, they would need to notify us, and then we would require all accounts in that population to change/reset their passwords?

 

-Etan E. Weintraub

Sr. Systems Engineer

Directory Architecture

IT@Johns Hopkins

Johns Hopkins at Mt. Washington

5801 Smith Ave.

Suite 3110B

Baltimore, MD 21209

Phone: 410-735-7945

E-mail: 

 

From:  [mailto:assurance-] On Behalf Of Michael W. Brogan
Sent: Wednesday, March 06, 2013 2:55 PM
To: 
Subject: [Assurance] RE: Passwords and Office365

 

Seems like IAP 4.2.3.6.3 is the relevant requirement:  “…the IdPO must have appropriate policies and procedures in place to minimize risk from this exposure.”

 

Michael W. Brogan

Technical Lead, Identity and Access Management

UW Information Technology, University of Washington

206-685-7521

 

 

From:  [] On Behalf Of Etan Weintraub
Sent: Wednesday, March 06, 2013 11:38 AM
To: ''
Subject: [Assurance] Passwords and Office365

 

Hi all-

We are in the process of implementing Office365 here at Hopkins, and based on the implementation guides, I had a question as to its impact on our ability to get Silver Assurance, so I figured I would ask here and see if anyone could give me an answer.

 

Basically, according to the information I can gleam, even using ADFS, at certain points (i.e. when using a mobile device to connect to the email service) the username and password are first sent to Microsoft servers, then back in to our environment and servers for authentication. Given that the username and password would be shipped securely (we are confirming that we can turn off all non-secure access points, but believe that it is available to do), but is “intercepted” and proxied through to our servers by the Microsoft servers, would this become an non-auditable point, and therefore potentially eliminate us from being able to get Silver?

 

-Etan E. Weintraub

Sr. Systems Engineer

Directory Architecture

IT@Johns Hopkins

Johns Hopkins at Mt. Washington

5801 Smith Ave.

Suite 3110B

Baltimore, MD 21209

Phone: 410-735-7945

E-mail: 

 

 




Archive powered by MHonArc 2.6.16.

Top of Page