that's much clearer Glenn, much appreciated.
There's an extra step we'll need though. The claims from OIDC are minimal so we need to query either the graph api or local LDAP to get all the attributes needed for access. Essentially, the OIDC step is to authenticate the user and get their username (and set them up for non SAML SSO), then branch out from there to get their attributes to send to the SP (many of which need a lot). I don't think we sync enough stuff to the cloud just now to make the graph api worthwhile, so we'd have to then query LDAP using the username from the STS.
lots of food for thought and thanks again for that explanation.
Alistair
________________________________________
From: Discussion list for Shibboleth developments <[log in to unmask]> on behalf of Glenn Wearen <[log in to unmask]>
Sent: 01 November 2018 14:25:04
To: [log in to unmask]
Subject: Re: SAML/OIDC auth
Hi Alistair
We have a standard Shibb endpoint, so the flow is
SP -> /idp/profile/SAML2/Redirect/SSO -> /idp/Authn/RemoteUser -> /oidc -> Azure STS -> /oidc (with unique_name claim) -> /idp/Authn/RemoteUser (with REMOTE_USER populated by mod_audth_oidc) -> SP
Regards
Glenn
On 01/11/2018, 14:04, "Discussion list for Shibboleth developments on behalf of Alistair Young" <[log in to unmask] on behalf of [log in to unmask]> wrote:
thanks Glenn,
how are the two Location reached from the endpoint in the SAML metadata? If our normal SAML SSO endpoint is /s2 I want the next page to be the the Azure STS login page. Does the Azure replyUrl have anything to do with /idp/Authn/RemoteUser ?
e.g. is the flow:
sp -> /s2 -> /oidc -> STS (login) -> /idp/Authn/RemoteUser (claims)
Alistair
________________________________________
From: Discussion list for Shibboleth developments <[log in to unmask]> on behalf of Glenn Wearen <[log in to unmask]>
Sent: 01 November 2018 13:57:58
To: [log in to unmask]
Subject: Re: SAML/OIDC auth
Hi Alistar,
Apologies, it was the conventional RemoteUser handler we used, these are the paths we protected;
<IfModule mod_auth_openidc.c>
<Location /oidc>
AuthType openid-connect
# allow only for specified domain. here is sample for heanet.ie
Require claim "unique_name~\w+\@myorg\.com$"
</Location>
<Location /idp/Authn/RemoteUser>
AuthType openid-connect
# allow only for specified domain. here is sample for heanet.ie
Require claim "unique_name~\w+\@myorg\.com$"
</Location>
Regards
Glenn
On 01/11/2018, 13:51, "Discussion list for Shibboleth developments on behalf of Alistair Young" <[log in to unmask] on behalf of [log in to unmask]> wrote:
thanks for that, I could only find a reference to IdPAuthExternal which is deprecated and there doesn't appear to be an equivalent in IdP 3.x other than stuff in the 'BackDoor'. Is the BackDoor generally ok to use?
https://wiki.shibboleth.net/confluence/display/SP3/BackDoor
Alistair
________________________________________
From: Discussion list for Shibboleth developments <[log in to unmask]> on behalf of Glenn Wearen <[log in to unmask]>
Sent: 01 November 2018 13:40:45
To: [log in to unmask]
Subject: Re: SAML/OIDC auth
Yes, using Shibb AuthExternal and Apache mod_auth_oidc, works quite well for us
Regards
Glenn
On 01/11/2018, 13:01, "Discussion list for Shibboleth developments on behalf of Alistair Young" <[log in to unmask] on behalf of [log in to unmask]> wrote:
Has anyone delegated IdP authentication to OIDC? in particular a Micrososft Azure STS? We have two 'SSO' routes, one SAML, the other Azure OIDC and of course they don't talk to each other but they could if the IdP was registered as an Azure tenant app and switched from LDAP to OIDC for authentication.
So in a typical SAML WBSSO flow, there would be an extra redirect to send the user to the STS and back rather than present a login page for local LDAP authentication. SAML would continue once the claims had come back from the STS in the browser.
I was wondering if anyone has seen this before or whether the I2 IdP supports such an 'sso bridge'? I see there's something called Okta which seems to be very complicated and very expensive but I'd prefer if the IdP could just use the Azure STS for its authentication.
thanks,
Alistair
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
########################################################################
To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1
