Office 365 ECP Issues

[Lalith Jayaweera]

Hi Scot,

Thanks for the detailed answer, we had ECP with Apache (SASL)
authentication on V2 working with no issues hence was trying the same with
V3,  Before I try out password flow, just to give you an update, I did
below with the current setup but same failure....however not going to go
too much into it as I already starting configuring password flow.

 p:authenticationFlows="#{{'RemoteUserInternal'}}" in ECP profile



with idp.authn.flows=Shibcas|RemoteUserInternal  in idp.properties but
failed.


With SASL we have more control over the LDAP filters, because in Office 365
ECP, only local part of UPN will hit the IDP,


I am going to try below to enable the password flow and see. Please advice
if anything wrong in my steps


*Remove above authenticationFlows from the ECP profile

* change idp.properties  to idp.authn.flows=Shibcas|Password

* remove the Apache configuration which protected ECP URL


and configure the ldap.properties to do the authentication,  so I believe
similar to SASL I can have something like below for auth filter in
ldap.properties because I only receive local part of UPN and in our ldap
there is no such direct attribute to bind,


idp.authn.LDAP.userFilter = (mail={user}@ourdomain.com)


Please advice anything wrong or require any other configuration



Thanks



















On Wed, Jul 19, 2017 at 2:28 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> Also, it goes without saying that you can't just do things blindly here. I
> made a suggestion in context. When I said to tell the ECP profile to direct
> itself to use RemoteUserInternal, that was with the implicit assumption
> that you were going to configure that flow in accordance with the
> documentation, and enable it via the idp.login.flows property expression.
> If you did none of these things, then, no, it's not going to do anything
> but fail.
>
> The V3 ECP support is designed to be used with the Password flow to make
> it simple for people to deploy without extra work since most people were
> using the password support in V2.
>
> The authenticationFlows property isn't normally something you would set,
> but I think it's the most natural way to get the system to support two
> separate "isolated" flows that work separately for browser and ECP. You
> would configure each login flow separately, but correctly, enable both in
> the property setting that turns on the flows, and then direct ECP to use
> one and the browser-based flows like SAML2.SSO to use the other. Then
> they're both functioning essentially in isolation but together in the
> system at the same time.
>
> I have never done this specifically, but that's my general guess as to the
> simplest way to do it with the least chance to introduce side effects.
>
> -- Scott
>
> On 7/18/17, 11:31 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
> On 7/17/17, 11:34 PM, "users on behalf of Lalith Jayaweera" <
> users-bounces at shibboleth.net on behalf of ljayaweera at gmail.com> wrote:
>
> > you mean something like below, but same failure result ....with
> authentication issue
>
> Then you need to use logs, read the documentation, determine what actually
> is going wrong, etc. You are running a complicated set of options and
> approaches and that means you will have to learn and understand much more
> than somebody following the more advisable, out of the box, approaches.
>
> -- Scott
>
>
>
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170719/5cbc8194/attachment.html>