Date: Fri, 29 Mar 2024 07:03:00 +0000 (UTC) Message-ID: <1244209242.7583.1711695780935@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7582_1907327753.1711695780934" ------=_Part_7582_1907327753.1711695780934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This documentation will help you integrate your identity service= s with Blue Jeans through Internet2=E2=80=99s NET+ program. Associated port= ions of the NET+ Identity Guidance for Services are noted below.
Blue Jeans offers Service Provider (SP) Initiated logins using dedicated= customer landing pages. Each customer will have a dedicated landing page t= hat is exposed to end-users. The landing page typically will have a =E2=80= =9CLogin=E2=80=9D button that will re-direct the user to a page hosted by t= he customer where the user will enter their credentials. Once authenticated= , the user gets re-directed to Blue Jeans web-app where the user will get a= ccess to the service.
Blue Jeans also supports Identity Provider (IdP) initiated logins throug= h acceptance of unsolicited assertions.
Blue Jeans can consume the following attributes in a SAML response:
Blue Jeans Attribute |
Recommended SAML Attribute Name |
Optional |
---|---|---|
User ID |
SAML 2.0 Persistent NameID |
No |
urn:oid:0.9.2342.19200300.100.1.3 |
No |
|
First Name |
urn:oid:2.5.4.42 |
Yes |
Last Name |
urn:oid:2.5.4.4 |
Yes |
Title |
urn:oid:2.5.4.12 |
Yes |
Phone |
urn:oid:2.5.4.20 |
Yes |
Company |
urn:oid:2.5.4.11 |
Yes |
Mapping of incoming SAML attributes to attribute fields persisted by Blu= e Jeans can be configured via the Blue Jeans admin console by each organiza= tion.
Blue Jeans requires a unique, persistent, non-reassignable identifier pe= r user that can be sent as either an attribute or a SAML 2.0 Persistent Nam= eID. This identifier is treated as opaque by Blue Jeans and so can take mos= t forms and characters.
Users are able to change any visible attribute(first name, last name, ti= tle, phone, company, email) in their Blue Jeans account independent of the = values sent by the IdP. Changes to user attributes received from the IdP af= ter a user has been initially provisioned will overwrite prior IdP-supplied= values but not user-supplied values.
The attribute mapped to email should contain a routable email address in= order to receive important service related communication sent by Blue Jean= s. Email addresses must be unique.
Blue Jeans does not support any explicit attribute to manage user access= control. The IdP can enforce a policy to not release attributes to Blue Je= ans for unprivileged users, and users without required attributes will not = be able to use the application.
Administrators are flagged by Blue Jeans. Initial login to setup a SAML = 2.0 relationship is performed using Blue Jeans credentials given through an= out-of-band support mechanism. Subsequent administrative logins can happen= either using these credentials or using federated identity. There can be m= ultiple administrators per organization.
Blue Jeans user representations are provisioned using dynamic front channel provisioning (3.1), so any user that can successfu= lly authenticate to the IdP with release of the attributes required for the= Blue Jeans service are provisioned in Blue Jeans. The primary key for the = user record will be the identifier selected by the organization.
Users that have an existing Blue Jeans account will be associated with a= federated identity the first time the user logs in if the email addresses = match.
Deprovisioning of user data is a manual process and can only be initiate= d by contacting the Blue Jeans support team.
Blue Jeans logs out a user locally and supports the ability for organiza= tions to configure a URL to redirect a user to upon successful local logout= . Blue Jeans does not support single logout through SAML 2.0 or back-channe= l mechanisms.
Blue Jeans uses SAML 2.0 software that has known compatibility with most= commonly used SAML 2.0 implementations, including Shibboleth, simpleSAMLph= p, ADFS, Okta, OneLogin, AssureBridge, VMWare Horizon, Ping Identity, and m= ore.
Blue Jeans only supports unencrypted SAML assertions at this time.  = ;It also requires that both asserti= ons and responses be signed. For the Shibboleth v3 IdP, a relying par= ty configuration similar to the following should work:
= <bean parent=3D"RelyingPartyByName" c:relyingPartyIds=3D"http://samlsp.b= luejeans.com"> <property name=3D"profileConfigurations"> <list> <bean parent=3D"SAML2.SSO" p:encryptAssertions=3D"fa= lse" p:signAssertions=3D"true"/> </list> </property> </bean>
In the BlueJeans->Admin->= Group Settings->Security form, the "Login URL" parameter must be configu= red to point to an endpoint that supports HTTP-Redirect.
SAML 2.0 metadata for the Blue Jeans SP is available at http://b= luejeans.com/support/saml-metadata.xml. Blue Jeans is not able to consu= me metadata today.
Blue Jeans has written some general instructions for a standard ADFS con= figuration which are available at http://bluejeans.force.com/Knowledge= Search/articles/Knowledge_Base/Configuring-ADFS-2-0-for-SSO-with-Blue-Jeans= /p