Office 365 ECP Issues

[Lalith Jayaweera]

changed to idp.authn.flows=Shibcas

Both ECP and WebProfile working

Thanks

On Wed, Jul 19, 2017 at 8:18 PM, Lalith Jayaweera <ljayaweera at gmail.com>
wrote:

> Looks like things authenticating, just that, instead of going to CAS login
> screen now everything goes to LDAP login screen which is in IdP
>
> Do I have to again use p:authenticationFlows in the profile
>
> I thought I dont have to use it,
>
> Please advice any change of properties required
>
> On Wed, Jul 19, 2017 at 2:52 PM, Lalith Jayaweera <ljayaweera at gmail.com>
> wrote:
>
>> 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/1040ec83/attachment-0001.html>