Print

Print


Azure is _already_ a SAML IdP - you don't need to do anything to make it one!

 To use it, for each SP,  you need to create an "Enterprise Application" object in portal.azure.com,  you put the entityID of the SP and it's ACS in there and you can customize the attributes that are going to be released in there too.   There is no place to put metadata like you would in shib.   From that object you get a URL for the IdP metadata to give to the SP.  Bingo - job done.   I was a bit gobsmacked when I was able to hook up the shibboleth SP under my desk to Azure and it all worked just the same as against a shib IdP (that was about 18 months ago and we haven't looked back!).

Attribute transformation isn't as flexible as the shibboleth resolver so there may be some things you want to do that you can't.  But it's fine for bog standard things like Blackboard that just want basic authentication and a couple of identifying attributes.

For everything else we've kept the Shib IdP, but it's in the cloud and we don't have to do anything to maintain it any more.  As I say - it authenticates against Azure - BUT - it does an ldap lookup through a tunnel to get the attributes from an adlds instance on-prem.   We are musing over whether to ship up some more bits to Azure to get rid of that reliance as AIUI the Overt IdP can now get the attributes it needs from Azure too.   It would be nice to get rid of any reliance on local infrastructure.   Azure does have a fairly limited attribute set for putting things in and you can't extend it - but we reckon there's enough.  We reckon we could do a lot of things by Group membership - "if member of X release Y in ePE"

You should have come to our presentation at the Teams event in Nottingham in July, we were talking about this there.  You can have the slides if you like (but they aren't very standalone).

Cheers
Andy


-----Original Message-----
From: Discussion list for Shibboleth developments <[log in to unmask]> On Behalf Of Alistair Young
Sent: 01 November 2018 14:38
To: [log in to unmask]
Subject: Re: SAML/OIDC auth

thanks Andy,

that's pretty much what we're working towards. Do you have Azure working as a SAML IdP or is there one of them in the cloud too?

If Azure is an IdP, is it 'easy' to generate attributes from existing ones? e.g. generating entitlements from DNs?

Alistair

________________________________________
From: Discussion list for Shibboleth developments <[log in to unmask]> on behalf of Andy Swiffin (Staff) <[log in to unmask]>
Sent: 01 November 2018 14:32:40
To: [log in to unmask]
Subject: Re: SAML/OIDC auth

Our cloud Shib IdP authenticates against Azure, but not oidc, it does it using SAML .  We also have several other things both on-prem and cloud authenticating using SAML against Azure.  E.g. our on-prem Blackboard which uses the Shibboleth SP now authenticates against Azure (we moved it from Shibboleth), ditto SITS eVision and a few other things.

When a user authenticates to a shibboleth resource they get redirected to the O365 login screen, but not if the user is already directly authenticated to Azure (O365 etc).  Hence we get SSO between Shib resources and Azure resources, it doesn't matter which one you go to first.

They've just rolled out the new windows 10 student desktop and they're all Azure joined - so now there's no browser authentication needed at all - if you login to one of those machines you're into everything by SSO anyway, using either Edge IE or Chrome.

Cheers
Andy


-----Original Message-----
From: Discussion list for Shibboleth developments <[log in to unmask]> On Behalf Of Alistair Young
Sent: 01 November 2018 13:01
To: [log in to unmask]
Subject: SAML/OIDC auth

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

The University of Dundee is a registered Scottish Charity, No: SC015096

########################################################################

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

The University of Dundee is a registered Scottish Charity, No: SC015096

########################################################################

To unsubscribe from the JISC-SHIBBOLETH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=JISC-SHIBBOLETH&A=1