assurance - RE: [Assurance] RE: Passwords and Office365
Subject: Assurance
List archive
- From: Etan Weintraub <>
- To: "<>" <>
- Subject: RE: [Assurance] RE: Passwords and Office365
- Date: Thu, 7 Mar 2013 14:10:41 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport05.merit.edu; dkim=neutral (message not signed) header.i=none
As Brian stated, separate passwords aren’t what we are trying to implement with. The project leads want to use the same credentials, and provide some level
of SSO between our environments. Can anyone speak definitively on whether my proposed solution of requiring Microsoft to notify us if they are compromised and us forcing password resets on all accounts that use that system would be sufficient to meet the requirements
of the IAP? -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:]
On Behalf Of Brian Arkills 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:
[]
On Behalf Of Michael R. Gettes 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 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 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: |
- [Assurance] Passwords and Office365, Etan Weintraub, 03/06/2013
- [Assurance] RE: Passwords and Office365, Michael W. Brogan, 03/06/2013
- [Assurance] RE: Passwords and Office365, Etan Weintraub, 03/06/2013
- Re: [Assurance] RE: Passwords and Office365, Michael R. Gettes, 03/06/2013
- Message not available
- RE: [Assurance] RE: Passwords and Office365, Brian Arkills, 03/07/2013
- RE: [Assurance] RE: Passwords and Office365, Etan Weintraub, 03/07/2013
- RE: [Assurance] RE: Passwords and Office365, Brian Arkills, 03/07/2013
- Re: [Assurance] RE: Passwords and Office365, Steven Carmody, 03/07/2013
- RE: [Assurance] RE: Passwords and Office365, Etan Weintraub, 03/07/2013
- RE: [Assurance] RE: Passwords and Office365, Brian Arkills, 03/07/2013
- RE: [Assurance] RE: Passwords and Office365, Etan Weintraub, 03/07/2013
- [Assurance] RE: Passwords and Office365, Etan Weintraub, 03/06/2013
- [Assurance] RE: Passwords and Office365, Brian Arkills, 03/06/2013
- Re: [Assurance] RE: Passwords and Office365, Cantor, Scott, 03/06/2013
- [Assurance] RE: Passwords and Office365, Michael W. Brogan, 03/06/2013
Archive powered by MHonArc 2.6.16.