Non-web Clients

[Peter Schober]

* lalith jayaweera <j_lalith at hotmail.com> [2015-07-30 07:19]:
>  When setting up Shibboleth with Basic Http authentication for ECP,
>  to check Office365, is it correct to state login 'username' will be
>  email. Hence in the apache block for the ECP,  the AuthLDAPURL will
>  be something like below.
>  
> AuthLDAPURL ldap://ldap.example.org/ou=People,dc=example,dc=org?mail
> 
> because Looking at lot of non-web thick clients, e.g. Office365
> clients, outlook profiles,  etc. they all start with email address
> as the username during the set up progress, because I did not get
> any hit to the IdP server at all.

All of this is outside the IDP, it seems. How you do HTTP Basic Auth
from your Apache httpd web server to your LDAP directory is up to you.
If you get no "hit to the IdP server at all" (whatever that means
specifically) I'd say this won't have anything to do with the kind of
ldap search filter you use from httpd to the LDAP DSA.

> Issue is our current Web SSO is, the username is 'UID' (staffId) not
> email address. Is it possible to facilitate both?

What you can and cannot do with httpd as LDAP client and an unnamed
LDAP implementation on the server is not something Shibboleth can help
you with.  The httpd documentation can, though:
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authldapurl

  attribute
    The attribute to search for. Although RFC 2255 allows a
    comma-separated list of attributes, only the first attribute will be
    used, no matter how many are provided.

> After setting up ECP and Windows Azure side, we tried to Test the
> Office365 ECP integration on a real mobile device(iPhone), that is,
> I tried to add a account of type exchange using the native mail
> client app in iPone6, but it failed. I am having doubts whether it
> is to do with no email username for login in ECP. Because setup
> starts asking for the with email.

I doubt the above description will give anyone sufficient technical
detail to tell you what the problem is.

It seems all of this is about httpd and LDAP, so look into your LDAP
directory server's logs if you're unsure that part is correct.
-peter