- This topic has 4 replies, 3 voices, and was last updated 1 year, 1 month ago by
.
-
Posts
-
On Oct 25, the ‘.br’ (Brazil) Identity Providers were removed from InCommon metadata. If you are from one of the affected institutions, please sign up to FABRIC using an alternative Identity Provider. CILogon team is looking into this issue, however we don’t have an ETA for a resolution.
InCommon confirms that there is a problem with the CAFe federation metadata, resulting in all Brazilian IdPs being dropped from eduGAIN (and thus InCommon). The eduGAIN staff are working to understand the problem on the CAFe federation side and the plan to fix it. Currently there is no ETA on a fix.
I noticed this problem yesterday (26/10), and I have already made a request to “Account Issues” to use Google as an identity provider, since my institution (UFES) uses Gmail as its institutional email.
As my FABRIC account was created with this email, I did not lose my data and registration in the project in which I participate.
It may be more interesting to have more than one email account registered with FABRIC or use Github as an identity provider, if possible.It may be more interesting to have more than one email account registered with FABRIC or use Github as an identity provider, if possible.
FABRIC already supports logically linking multiple email/IdP credentials together under the same user account through a COmanage backend that is part of CILogon’s authorization and group management stack.
There are some caveats when doing this however.
- Even though FABRIC can logically map more than one email to an individual user, Jupyterhub will allocate storage based on a user email attribute. As such the user will not see a consistent storage backend when logging into FABRIC using differing IdPs that are accessed through different email addresses
- If however the email address is consistent, then Jupyterhub storage will be consistent even when the IdPs differ from each other
- Some IdPs operate on alias email addresses and COmanage may know about one or more valid emails that are aliases of a primary or official email address. If these exist in COmanage then FABRIC will find them and the user may choose to use any of the valid emails as their “preferred email” for contact purposes
GitHub isn’t necessarily an identity provider in and of itself. In most cases GitHub is proxying your identity from another authority (e.g. Google) and simply relaying the claims it knows about you from the proxied provider.
This is analogous to what CILogon does in its federated identity model. It forwards the claims retrieved from your chosen identity provider along with additional attributes that it adds on for bookkeeping your information as being “unique” amongst 4000+ other identity providers.
- You must be logged in to reply to this topic.